[Box Backup] LLONG_MAX configure mistake with gcc 4.1.1 (Linux)

[boxbackup@fluffy.co.uk]

Looking at the headers, and googling around (the standards seem to be pretty unpleasant with regards to LLONG_MIN/MAX), I think it's not too clear what should be the right behaviour.

LLONG_MIN/MAX seem to be ISO C 1999 only (and newer), and don't seem to apply to C++ standards at all. Certainly they're not defined on my system unless I pass -std=iso9899:1999, and that's not allowed for g++ (you get a compiler warning). This Google Answers entry explains it better than me:
http://www.google.com/answers/threadview?id=334912

That page also gives a more correct method of determining these limits in C++ (based on std::numeric_limits<long long>), so perhaps that would be more portable?

As to why our systems are different (we seem to be running the same version of GCC), what version of glibc are you using? I'm using 2.3.6 and am wondering if it might be changed behaviour in one of the later versions (currently marked as unstable in Gentoo, so I've avoided trying them).

So, a few approaches here:
1. Change to not use LLONG_MIN/MAX at all and use std::numeric_limits<> instead.
2. Find a way to convince GCC to define those constants always (perhaps glibc-dependent) - but this just hides the compiler 'feature' that trips up the sanity check.
3. Fix the configure step to either use a different sanity check when it has manually had to determine LLONG_MIN/MAX.

I'm happy to help out if you'd like me to investigate any of these (although I'm at a loss to solve [2], I think, having had a brief try). I notice your name is on the file infrastructure/m4/ax_check_llong_minmax.m4 so you've got some history here...

I'm thinking that a suitable configure check could try std::numeric_limits<> first, then LLONG_MAX/MIN, then give up and determine it manually. I've not had too much experience writing configure steps, but I reckon this might be a good opportunity to learn if you think it would help and you'd consider the patch for inclusion.

There's still going to be the issue of the sanity check being incompatible with GCC 4.1, but if we can reliably extract the limits from definitions instead we should never see that stage reached.

Thanks for the ongoing help,
Stuart

stuart@hickinbottom.demon.co.uk wrote:
> Yes, there's definitely a difference because my Gentoo system doesn't
> find the definitions for LLONG_MAX during configure and then goes on to
> try to determine its own (where this GCC 4.1.1 behaviour then causes
> trouble).
> 
> I've got limits.h (two versions of it - seems to be one 'public' one in
> /usr/include and one GCC private version in
> /usr/lib/gcc/i386-pc-linux-gnu/4.1.1/include/limits.h), and they do
> contain the definition of LLONG_MAX/MIN so I'll need to try to track
> down the header processing to understand the reason those symbols aren't
> defined on my system.
> 
> Whilst it might not hit as many people as I first thought, I'm still
> pretty convinced it won't compile for people with GCC 4.1.1 if they
> don't have the definitions for LLONG_MAX and LLONG_MIN (as seems to be
> the case on my Gentoo Linux).
> 
> Anyway, it's late so I'll think this over for a while.
> 
> Stuart
> 
> Martin Ebourne wrote:
> > On Thu, 2006-06-15 at 21:00 +0100, Stuart Hickinbottom wrote:
> >> I've done some more investigation and I believe GCC 4.1 is applying
> >> optimisations (whether or not you pass -O<anything>) that cause the
> >> sanity check of the determined/compiler-supplied LLONG_MIN/LLONG_MAX to
> >> always fail.
> > 
> > I'm using FC5, gcc 4.1.1, x86_64. The test program fails here too. Quite
> > scary actually. The gcc compiler aborts(!) but g++ compiles it. If I
> > compile to assembler then two of the four "sanity fail" strings don't
> > even appear in the output, this with optimisation off! I only really do
> > sparc, arm, and m68k programming so I don't really know what's going on
> > in the assembler code and can't really be bothered to try and figure it
> > out.
> > 
> > But Box configures and compiles ok:
> [snip]
> > 
> > Note that it's not running the program, it's finding the definitions in
> > limits.h. How come they're missing on your system?
> > 
> > Seems gcc is reassuringly broken though.
> > 
> > Cheers,
> > 
> > Martin.
> > 
> > _______________________________________________
> > boxbackup mailing list
> > boxbackup@fluffy.co.uk
> > http://lists.warhead.org.uk/mailman/listinfo/boxbackup
> > 
> _______________________________________________
> boxbackup mailing list
> boxbackup@fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>