RE: snapshot of Lua 4.1 (work) problems with VC++

["Eric Ries" <eries@...>]

Having mucked around with the internals of Lua 4.0 a fair bit now, it would
be nice if there were some more coding conventions in place to help make it
clear to those of us who are a bit slow when a certain function-call is a
macro and when it is not. Just my $.02

Eric

> -----Original Message-----
> From: owner-lua-l@tecgraf.puc-rio.br
> [mailto:owner-lua-l@tecgraf.puc-rio.br]On Behalf Of Peter Loveday
> Sent: Thursday, November 01, 2001 3:21 PM
> To: Multiple recipients of list
> Subject: snapshot of Lua 4.1 (work) problems with VC++
>
>
> Thanks for giving us access to this in-progress version!
>
> I've found a bit of a problem compiling it for windows. (with VC++ sp5)
>
> This seems to be due to an obscure bug in the Microsoft pre-processor,
> which gets upset with substitution of the G(L) macro from within the
> (new) cast(t,x) macro.
>
> For example, the code in lgc.c in checkMbuffer()
>
> luaM_reallocvector(L, G(L)->Mbuffer, G(L)->Mbuffsize, newsize, l_char);
>
> where luaM_reallocvector() uses cast() a few times, seems to make the
> preprocessor attempt to substitute the member variable G (from L->G) as
> a macro instead of treating it as a variable.  This of course causes
> it to get the code completly wrong.
>
> The Intel compiler for VC++ does not have this problem, and while it is
> clearly a microsoft bug, in the interests of compatibility
> perhaps something
> could be done.  The true cause of this problem seems to stem from the
> fact the macro G(L) has the same name as the member variable 'G'
> in Lua_state.
>
> If either were renamed then the problem would no longer exist;
> and in general
> I'd say having defines and variables (or members) of the same
> name is probably
> best avoided, even if the macro does require an arg in this case.
>
> Thanks for your time!
>
> Love, Light and Peace,
> - Peter Loveday
>
>