Re: Bug in Lua when using signed long

[Mark Hamburg <mark@...>]

On Dec 13, 2009, at 10:54 AM, Mike Pall wrote:

> Mark Hamburg wrote:
>> Having lua_pushinteger work with ptrdiff_t is convenient and it
>> would be much less convenient if it took something considerably
>> shorter.
> 
> I'm not so sure about that. It depends more on the individual
> programming style. The few Lua/C API functions that deal with
> lua_Integer are probably less used than the ones that deal with
> int (some are macro wrappers for the former).
> 
> And I bet most developers are not aware that lua_Integer has a
> platform-specific size. Add to that the confusion about 'long' on
> 64 bit platforms (it's 32 bit on WIN64 and 64 bit everywhere else).
> Some C code is likely to be broken on some 32 or 64 bit platforms
> or has security holes due to unnoticed overflow conditions.
> 
>> The "problem" is that there isn't a standard numeric
>> type which means "an integer that fits exactly within a double".
> 
> But it would make sense to use an out-of-the-box configuration
> where lua_Integer is a subset of lua_Number. One could just use
> LUAI_INT32.
> 
> Alas, it's a bit too late to fix that now. Changing lua_Integer
> would break the Lua 5.1 ABI.

My primary use case for integers exceeding the range of ints are file offsets. These will pretty much always fit in the precision afforded by double but often not in the precision afforded by int.

> 
>> I could see having versions of the APIs -- possibly in lauxlib
>> -- which actually check things like pushed integers being in
>> range, retrieved numbers actually being integers, etc..
> 
> This could become expensive and you'd need lots of variations for
> these. And it would be against the strict 'no handholding' policy
> of the Lua/C API. I'd say it's best to add your own assertions.

That was why I proposed them for lauxlib. There isn't any standard place that's further out from the core. For those not using pre-built binaries, tying such checks to LUA_USE_APICHECK could make sense. (This failed because you overran the precision guarantees or this number didn't fit in a LUA_INTEGER, etc.) I could also see doing something to explicitly label them as slow.

Mark