On 9/8/13, Tomas Hajny <xhaj...@hajny.biz> wrote: > Why do you believe that ExpandFilename is not threadsafe (on Windows or > any other platform)? .. > The only platform specific part inside > ExpandFilename is a call to GetDir function retrieving the current > directory. If that is not 'threadsafe' by itself (on Windows), then your > statement is correct,
And that is exactly the point. GetDir calls GetCurentDirectory and MS says (see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364934%28v=vs.85%29.aspx) that multithreaded applications should not call GetCurrentDirectory. > that some other thread may change the current directory during execution > of ExpandFilename - well, that may be the case, but that is not special > for Windows and it should be the responsibility of the programmer either > not to change the current directory in other threads, But GetDir just does that: it changes the current directory if it tries to find the current directory on a drive that is not the current drive. It then calls SetCurrentDirectory with only the drive letter, and calls GetCurrentDirectory again. Why would I forbid my users to specify relative paths? How would you feel if, as Jürgen suggests we prepend anything with \\?\, you now cannot do a simple: C:\Devel\Foo>fpc bar.pas -Fu..\MyLib But you must do C:\Devel\Foo>fpc C:\Devel\foo\bar.pas -FuC:\Devel\MyLib, because the compiler is mutithreaded (this may be untrue, but just for the sake of the argument), so expanding the filename is unsafe? For the record: I am not stating that this (handling '\\?\') _must_ be "fixed" in fpc, I am perfectly happy with "you should handle that on the users side", which would mean NOT calling DoDirSeparators (and any function that uses that) on such a filename. It would be nice however if a "formal" point of view from the fpc core team was given on this subject. Bart _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
