| This is not a change in behavior -- it is simply a bug. Using both kinds of
slashes should still work for all pathnames other than the orchestra or
score in the current build.
The function csoundGetDirectoryForPath() is only used by the code that adds
the orc and sco directories to the path variables. (I don't understand what
an orc filename is doing in the CSD options though ...)
The reason it does not work in this case is that the function does not call
the csoundConvertPathname() function which is usually called when opening
files. csoundConvertPathname() still needs some more work to be correct for
all cases, but I think it will work fine for converting between / and \.
I was thinking about this before: I think that csoundGetDirectoryForPath()
could be replaced by csoundSplitDirectoryFromPath() which does something
very similar but already converts path separators. The former returns the
full path of the directory containing a file (even if a relative path only
is provided). The latter returns just the path portion of the pathname
(relative or absolute).
csoundGetDirectoryForPath() is used to set the default search paths but
these do not have to be absolute paths. They should work just fine as
relative paths. Even if we want to keep csoundGetDirectoryForPath(), it has
some extra logic for the case of a file being in the root directory -- logic
that I believe is superfluous and could be removed. If we want to keep
csoundGetDirectoryForPath() with the functionality it has, then it could be
simplified by just calling csoundSplitDirectoryFromPath() followed by
csoundIsNameRelativePath() and then use getcwd() as it does now if the
result is relative.
I was not aware of any native APIs for manipulating paths -- besides, Csound
needs to handle them a little differently so that Unix, Windows, and Mac
paths will all be interpreted correctly on any platform. Indeed, you should
be able to use either Unix OR Windows separators in your orchestras and have
them work on both.
Anthony
Michael Gogins wrote on 11/26/06 1:53 PM:
> It used to be possible to specify pathnames for Csound on Windows using either
> Windows slashes (\ or \\) or Unix slashes (/). This is consistent with the
> behavior of the Windows system calls -- they all work fine for both kinds of
> slashes (although some Windows console commands such as dir now accept only
> Windows slashes).
>
> Now, however, if Windows slashes are not used in all Csound pathnames, in this
> case orc filenames in csd files, Csound fails with a memory allocation error.
> This is caused in where strrchr for DIRSEP is called
> without respect to the direction of the slashes in the pathname, returning an
> invalid length for a valid pathname that contains only Unix slashes.
>
> I would much prefer it if the original behavior was maintained, because I
> could then run the same scripts and orchestras on both Windows and Linux. I
> habitually use Unix slashes on Windows in the MSys shell, and try to keep my
> Windows environment as close to Unix as possible.
>
> Instead of coding all this behavior directly in the Csound API, it would have
> been a better idea to call native APIs on the supported platforms.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |