Re: Namespace pollution in lua.h

[Garth Dighton <gdighton@...>]

Unfortunately, you cannot always trust this rule, even with very
commonly used products. The company I work for uses the variable
"Status" as an argument to one of the API's in our product. Perfectly
reasonable. Guess which very common Unix library #defines this?

... 

X Windows #defines Status as int (for use as a return type)

Which means, of course, that no one can ever #include our product's
headers after the X windows headers.

Adolf Mathias wrote:
> 
> David Jones wrote:
> >
> > In message <3AFC22C4.6406FD80@gmx.de>, Edgar Toernig writes:
> > > David Jones wrote:
> > > >
> > > > #define index 9
> > > > #include "lua.h"
> > > > /* ... */
> > >
> > > I would say that if you do this kind of mess it's your turn to
> > > clean up afterwards ;-)
> >
> > Yes, well, _obviously_ index is a silly thing to #define.  Especially
> > before including Somebody Else's Header File.  But what am I allowed to
> > defined before including somebody else's header file?  stacksize, L, n,
> > s, len, u, tag, fn, str, filename, name?
> 
> I'd say #define'ing anything but symbols in all CAPITALS is dangerous
> and you should know exactly what you do, i.e. something like #define
> malloc(s_) my_favorite_malloc_debuger(s_). In my code, I also
> consistently use lowercase macro arguments with one underscore appended
> and I always put them in parentheses, except where it absolutely makes
> no sense. From this point of view however, the ubiquitous function
> argument lua_State *L is dangerous.My minor point of criticism to the
> authors of Lua is the not immediately obvious naming and capitalizing
> scheme in the Lua C source.
> 
> Dolfi
> 
> --
> Adolf Mathias              EMail: dolfi at zkm dot de  Web: www.zkm.de
> |||| / |< |||                 ZKM Basic Research - Grundlagenforschung
> P.B. 6919 D-76049 Karlsruhe, Germany; fon +49 721-8100-1511, fax -1509