Re: Quick question about lua_Integer (was: Lua 5.1 (work3) now available)

[Mike Pall <mikelu-0412@...>]

Hi,

Luis Carvalho wrote:
> Quick question concerning luaconf.h: why is lua_Integer now set to
> ptrdiff_t -- and before LUA_INT32 -- instead of long?

'lua_Integer' only affects four API functions. It does not affect the
types inside the core. The intention behind the type definition is to
offer an integer type with reasonable precision but without any undue
overhead (esp. wrt. type conversion and calling conventions).

'ptrdiff_t' was chosen because it is defined as part of C89 and happens
to be a signed type that is 32 bits for 16 bit or 32 bit CPUs and 64 bits
for 64 bit CPUs.

It's not appropriate to use 'long' since it is either too short or too long
in some data models (e.g. the LLP64 model (WIN64) or the L64 model (PS2)).

> On a C99 compliant
> machine, lua_number2int uses lrint that returns long. Also, without C99
> compliance, why cast to int instead of lua_Integer or LUA_INT32?

Umm, I guess this is an oversight. The use in ltable.c needs to cast to
an int, but the use in lapi.c needs to cast to lua_Integer. I guess the
macro should be extended with a type parameter.

> I'm probably missing something here, but I was glad to see lua_Integer
> set to long as it is Fortran's standard for integers and I'm currently
> using some Fortran libraries (you will probably see the result in a few
> months :)).

Most modern libraries written in C avoid the use of 'long' for portability
reasons. It's just not safe to assume anything about its size in bits
anymore.

And as far as Fortran on 64 bit platforms is concerned: INTEGER is still
equivalent to INTEGER*4 there. This means you may get unpleasant surprises
when using C's long type to pass integers to Fortran APIs on 64 bit machines.

See: http://www.unix.org/whitepapers/64bit.html

Bye,
     Mike