On Oct 12, 2005, at 12:54 AM, Brooks Davis wrote:
Can you elaborate on why you needed that? If there's a problem with
the stacktrace stuff on BSD, I'd like to make it either disable by
default or fix whatever is required to work properly on BSD.
There were a bunch of undefined symbols that I didn't track down.
Hopefully there's just a missing header file. I need to dig into it
more. I just disabled it because I was hoping that would be the only
issue. It wasn't but, I had stop working before I could try again
with stack traces enabled.
Ok. Right now, that section is only protected with #ifdef __GLIBC__,
so let us know what you find. The sooner, the better. :-)
On FreeBSD, eval is using 32-bit signed numbers internally on i386 (it
looks like it uses longs in general, but I haven't tested on a 64-bit
machine yet). This means that when you compute 2^31 you get INT_MAX +
1
which is negative. Subtracting one gives INT_MAX so you get the right
value despite the sign weirdness. Assuming I'm correct about longs
being used, we'll also be OK on 64-bit machines even if this code is
used to compute the maximum value of a 64-bit signed integer. It won't
work for unsigned numbers on either system though.
Gotcha. This makes me nervous, though (negative to positive magic); it
seems like it might not work on all platforms.
Another developer suggested just using a hex representation and avoid
this -- that seems to be simpler and much more portable (i.e., it
becomes string manipulation at this point, and doesn't depend on how
expr or the shell is implemented).
Thanks -- and keep the bug reports coming!
Aside: rc3 is coming shortly. We have some pending fixes that we want
to get in before cutting it, but there will likely also be an rc4 after
that because everything probably won't make the rc3 cutoff.
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
