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

["Dimiter \"malkia\" Stanev" <malkia@...>]

That's what I thought, until I stumbled onto this article:

http://blog.slickedit.com/2011/05/things-i-learned-during-the-64-bit-port/

The problem arises when varargs are used, so lua might (haven't checked) 
not be hitting the issue.

Take this example, from the article:

XtVaSetValues(xftXtTopLevelShell,
               XtNx, -1000,
               XtNy, -1000,
               XtNwidth, 100,
               XtNheight, 100,
               XtNmappedWhenManaged, False,
               0);

The 0 at the end is supposed to be NULL.

In 32-bit code everything is okay, but in 64-bit code, 0 is still 
32-bits (for certain compilers), and the function instead of receiving 
NULL receives something else.

It's just a pitfall to be aware, in other contexts I guess one can 
freely replace NULL with 0 (until someone else discover problem with that).


On 12/1/11 1:51 AM, Miles Bader wrote:
> Enrico Colombini<erix@erix.it>  writes:
> > > "0" should be perfectly acceptable in a pointer context; this sounds
> > > like a bug with the C compiler...
> >
> > That's in C++.
>
> It's acceptable in both C and C++.
>
> > In C, if I remember correctly, there is no automatic conversion and
> > the integer/pointer types could be incompatible on some hardware.
>
> You remember incorrectly.  Both C and C++ will automatically do the
> implicit conversion of a "0" in the source code to the appropriate
> pointer type in a pointer context.
>
> Remember, we're talking about "0" in the source code, not a run-time
> value of zero; a NULL pointer may indeed have a non-zero value at
> runtime.
>
> -Miles