Re: [ANN] Lua 5.2.0 (rc1) now available

[Roberto Ierusalimschy <roberto@...>]

> > The problem is that this cast is not completely useless.  In 32-bit
> > machines with lua_Integer defined as long long, the compiler will
> > generate more expensive code for nothing.  Moreover, we want to shift
> > an 'int'. We do not want to shift 64 bits, despite what the compiler
> > thinks.  Isn't there any way to indicate that fact in the code so that
> > it will not generate warnings?
> 
> Maybe. If your concern is that lua_Integer may be bigger than the
> machine word size, we may replace lua_Integer with another type which
> is exactly the size of that word, like ptrdiff_t.
> The following works for me:
> 
> #define twoto(x)	((ptrdiff_t)1<<(x))
> 
> It is also possible to cast the result rather than the operand. The
> following produces no warning neither on my system:
> 
> #define twoto(x)	(ptrdiff_t)(1<<(x))
> 
> At the extreme case, we can simply turn off the warning. I do not like
> this solution of course:
> 
> #ifdef _MSC_VER
> #pragma warning(disable:4334)
> #endif

All these options may result in sub-optimal code for some particular
sizes of ptrdiff_t and int.

Did you try this option?

  #define twoto(x)      (int)(1<<(x))

This asserts exactly what I want (I *really* want an int result, not a
ptrdiff_t), but I have some recollection that it does not work...

Another option is to put the cast in another place, between the 'twoto'
and the array indexing (as this interaction that is problematic, and
array indexing is a place where it makes sense to use ptrdiff_t, or even
size_t, instead of int). Can you give the exact places of the warnings?

I know this is very pedantic of my part, but I do not feel well writing
code that does not do what I want it to do (to shift an int with an int
result, which is exactly what the standard says it should do) because
one compiler thinks that I *may* want to do something else.

-- Roberto