Danny Smith wrote:
> Two reasons:
> 1) stat has problems with drive names like "D:" and with trailing
> slashes ("D:\user\").
> There were also some W9x vs NT differences that I can't remember now,
> but were reported to mingw-users.
> GetFileAttributes didn't have those problems.
> These problems can be worked around ( strip off the trailing slash then
> put back on if the last char is ':' but IIRC that workaround created
> problems with UNC
> roots like //server/share/ unless we do another special case for that).
> But why workaround if there is a more direct aproach?
> 2) stat is expensive. All we need here is if the string repesents a
> valid directory. We don't need file creation, modification or access
> time or size or drive or permissions.
> Virtually every function in MSVCRT.dll depends on the w32api. Why are
> you concerned that extensions to the runtime use the w32api? .
Your reasons are valid. I'm concerned because version 1.x of the
MinGW-runtime hasn't been dependent on anything else for building the
package. The mingw-runtime version 2 source package will be dependent
on w32api, so now we need to determine if the official release should
merge the two libraries. This is especially true since your build
process as currently designed expects to find the w32api source sitting
in the same parent directory as the mingw-runtime source. So, now I
have to modify my release tree for mingw-runtime and w32api. I must
think on this more.