Re: Possible bug in lbc?

[Luiz Henrique de Figueiredo <lhf@...>]

The file number.h is taken verbatim from GNU bc, which seems pretty solid
(it was last updated in 15-Nov-2000). I'm not an expert in the innards of
number.c but the author is either probably playing safe or it's a typo that
has gone unnoticed because all platforms define LONG_MAX. A quick google
search did not yield anything useful.

Sorry for top-posting.

> The "arbitrary precision library for Lua" (lbc) contains a file number.h which has this in it:
> 
> #define LONG_MAX 0x7ffffff
> 
> The number 0x7ffffff is 134217727 in decimal (note only 6 Fs).
> 
> Other definitions of LONG_MAX (eg. in limits.h) have it as:
> 
> #define LONG_MAX      2147483647L   /* maximum (signed) long value */
> 
> The number 2147483647 is 0x7FFFFFFF in hex (note 7 Fs, and this looks "more correct").
> 
> 
> * Is this a typo in number.h (in the lbc library)?
> 
> * Should it be changed? 
> 
> * Would the change make any difference to the behaviour of the library, which after all, handles numbers larger than 134217727?
> 
> * Or is there a valid reason the two LONG_MAX defines would have different values?