Which LIBC version under windows!!!!

[Tim Peters]

[David Bolen]
> ...
> I haven't kept up with threads on Unix recently, but aren't there at
> least two libc's - libc and libc_r for the re-entrant thread-safe
> functions?  Presumably if you built a shared library statically linked
> to libc_r couldn't you have a similar issue to what Python has on
> Windows?

It varies by Unix flavor, and is definitely a problem on some.  You can mine
the Python bug database for the horrid problems that result when people mix
libX and libX_r unwittingly on systems that care.

IIRC, the *real* reason to regret FILE* APIs on Windows is that they
frustrate attempts to mix code compiled under MSVC with code compiled under
other vendors' compilers (like Borland, I suppose).  There may well be other
cross-vendor incompatibilities too, but incompatible FILE layouts is the one
everyone (who tries this) seems to ram into at once.

> ...
> Windows may not have a perfect solution - maybe not even close - but I
> also don't think it's a trivial problem and I'm not sure it lends
> itself to such black and white (e.g., only 1 libc allowed) solutions
> as you propose.

Yes, there are many good "go as fast as possible" reasons to stick to the
non-threaded libraries when peak speed is necessary and you don't need
threads.  The tradeoffs are complex.  Along the other axis, the debug-build
libraries are invaluable (particularly the MS debug malloc/free, which
routinely catch memory-management screwups in Python development that even
efence doesn't catch on Linux), but too expensive to use in production.  The
MS developers aren't stupid -- they only appear to be <wink>.