Re: verification and linting of lua implementations

[David Manura <dm.lua@...>]

On Fri, Sep 30, 2011 at 8:57 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
> Do you know what is happening here?
>
> | -esym(767,setnvalue,TValuefields,NILCONSTANT,numfield,
> |           val_,num_,rttype,ttisnumber,ttisequal,checktag,
> |                 settt_,setobj,lua_number2int,lua_number2integer,lua_number2unsigned)
> |                 // macro defined differently in another module

The "lua_number2int,lua_number2integer,lua_number2unsigned" are
flagged due to the lack of a "#define LUA_CORE" in lctype.c (shouldn't
this be there?).  When lctype.c indirectly includes luaconf.h and
llimits.h, LUA_IEEE754TRICK doesn't get defined, so these lua_number2*
macros get defined differently than usual.  In practice, this doesn't
make a difference in lctype.c, which appears to only use
LUAI_DDEC/LUAI_DDEF/lu_byte, which don't depend on the lua_number2*
macros.  Moreover, these--and luai_hashnum which uses them--are not
part of the API spec, so user programs including lua.h without
LUA_CORE should not in theory use them either (if so, shouldn't these
be renamed luai_number2* ?), but even if they did then the fallback
"following definitions always work, but may be slow" will still be
acceptable.  So, it probably works but is a little confusing.

The other flagged macros above are due to the undef's in lobject.h.
For example, that warning is triggered if two different modules merely
contain this, even if they don't use the macros:

  #define A 1
  #undef A
  #define A 2
  //#undef A

Uncommenting the final #undef will inhibit this warning, but that's
not really practical here.  lobject.h does things basically like

  #define ttisnumber(o)		checktag((o), LUA_TNUMBER)
  #define nvalue(o)	check_exp(ttisnumber(o), num_(o))
  #undef ttisnumber
  #define ttisnumber(o)	(((o)->u.i.tt_ & 0x7fffff00) != NNMARK)

where nvalue ends up using the latter definition of ttisnumber.  This
should be correct but is a little confusing with undef.