[Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

[Thomas Wouters]

On Wed, Oct 11, 2000 at 12:40:41AM -0400, Tim Peters wrote:
> We need a glibc expert!  Anyone qualify?

No, at least not me ;)

> So the remaining question is why the same exp from the same library has
> different errno behavior depending on which version of Python it's called
> from.  *That* one we couldn't answer, after a fruitless time digging thru
> the Byzantine glibc source code trying to reverse engineer it.  Their exp
> *can* display different error behavior at runtime depending on several
> obscure things, but they're too obscure to relate back clearly to anything
> Python is doing.

Well, I've seen & heard about compilers doing slightly different things
depending on ANSI or K&R style C, so perhaps the presence of ANSI C
definitions triggered this. I sincerely doubt it, though, but you never
know, and it's fairly easy to test.

> I don't know what to do next.  I can't pursue it myself, and you've seen
> from the lack of replies to your posts that I'm the only who'll even listen
> to you <wink>.  Guido suggests that one big change in 2.0 is that we're
> including a lot more std headers than we used to.  It could well be that one
> of those #defines some God-forsaken preprocessor symbol one of whose five
> meanings (documented or not) is "use POSIX-conformant libm error reporting",
> but which someone #include'd in 2.0 to make (who knows?) sockets work right
> on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
> glibc.  Best hope now is for someone intimately familiar with glibc
> internals to jump in and own this.

Actually, there was some activity to define the right combination of
_GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not
sure what the end result was. If any #define changes the behaviour of glibc,
these would definately be it ! A simple test might be to compile 1.5.2 with
the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in
1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can
reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here,
and do some of the above tests.

Computers-suck-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!