lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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.

[
That's one *big* reminder I want to put out for the Lua authors:
whatever you supply as the out-of-the-box configuration *will* be
used by distributions. And it will stick, since they require a
stable ABI. So better plan ahead and work with the maintainers.

Previously every developer used a heavily-patched copy of Lua in
their local repositories. But Lua increasingly finds its way into
distributions. Many developers already rely on pre-built Lua
libraries and add-on modules.

Putting the head into the sand and saying "you can just patch
luaconf.h" is a pointless reply. They can't (it would break all
installed add-on modules) and they won't. Those times are over.

The (likely) Lua 5.2 ABI breakage will raise a storm of protest
for sure.
]

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

--Mike