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

[Martin Ebourne]

On Fri, 2006-06-16 at 09:33 +0100, stuart@hickinbottom.demon.co.uk
wrote:
> 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).

glibc-2.4. Seems stable enough on all my FC5 boxes, no idea how it would
be on your gentoo box. :)

> So, a few approaches here:
> 1. Change to not use LLONG_MIN/MAX at all and use
> std::numeric_limits<> instead.

I'd be happy to commit a patch that did this providing it was tested on
at least gcc 4.1, gcc 3.3, and msvc.

> 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.

No, that'll just keep breaking.

> 3. Fix the configure step to either use a different sanity check when
> it has manually had to determine LLONG_MIN/MAX.

Prefer doing it properly as per (1).

> (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...

Yes, I hadn't forgotten thanks.

> 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.

This would be an ok alternative to (1) if we find issues with it on
other compilers. But I prefer just doing it properly to start with.

> I'm happy to help out if you'd like me to investigate any of these 

It would help a lot if you sent a patch for this. (Switch to
boxbackup-dev list.) Otherwise it'll get stored in my mail client until
we're nearing the next release and I get time to look at it.

Cheers,

Martin.