[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: snapshot of Lua 4.1 (work) problems with VC++
- From: "Eric Ries" <eries@...>
- Date: Thu, 1 Nov 2001 15:35:04 -0800
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
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org]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