Re: small problem with LuaJIT FFI and gc method

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

Francesco Abbate wrote:
> > BTW: The use of size_t for anything but actual memory sizes is not
> >      a good idea. I guess int32_t would be a much better fit here.
> 
> Hmmm... this is not my choice but standard GNU coding practice and GSL
> library stick with it. They use systematically int for integers and
> size_t for unsigned integer. I don't know why the use size_t instead
> of unsigned int but why choose the size of the word with int32_t if
> you can just use a native int (unsigned or not) ?

If that's a standard convention, then it's utterly braindead.
Either use 'int' and 'unsigned int' or use matching pairs of the
fixed-size C99 types. On a 64 bit platform 'int' is still 32 bits,
but size_t is 64 bits. That's certainly not what was intended.

General rules: try to use the smallest possible type where it
matters (e.g. elements of an array). This reduces memory usage and
memory bandwidth. Use int32_t for all types where saving some
space doesn't matter. Use int64_t only when you really need the
extra bits. Avoid unsigned types, except for specific use cases.
Remember: 'unsigned' is a space optimization, and a really small
one, too (saves one bit).

In the context of the LuaJIT FFI, please remember that 64 bit
types need to be boxed and not all of the intermediate boxes can
be removed. Also, uint32_t is problematic due to extra conversions
and less optimizations. So prefer int32_t, even if the underlying
type never has negative values.

--Mike