lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


It was thus said that the Great Roberto Ierusalimschy once stated:
> 
> > I'm not sure how I feel about this.  It seems problematic.  For development
> > and initial testing, I don't define NDEBUG (so asserts are enabled) and yet,
> > here's some code that "arbitrarily" sets NDEBUG if some other define isn't
> > defined.  I know I can change the code, but I'd rather not have to patch it
> > if possible.  I know the intent is to avoid including debugging code by
> > default but I would think there would have to be a better way.
> 
> This definition is inside LPEG. Are you talking about development and
> initial testing of LPEG itself?  Otherwise, the "arbitrarily" definition
> of NDEBUG inside LPEG should not botter you.

  Not directly.  I have this program at work that uses Lua and LPeg.  The
code is structured as:

	project/
		foo/
		foolibs/
		third_party/
			lua
			lpeg
			...

I have one top level Makefile that compiles everything
(non-recursively---it's about 57K in size).  That way, everything is
compiled with the same options, which default to:

	gcc -std=c99 -pedantic -Wall -Wextra -g -Ithird_party/lua-5.1/src -Ithird_party/uuid/src -Ithird_party/spcdns/src -I/usr/local/include -c ...

Note the lack of -DNDEBUG here.  That is intentional as it helps me test the
program (assert() is enabled for instance).  And yes, there are warnings
that pop out:

third_party/lua-5.1/src/loadlib.c: In function ‘ll_sym’:
third_party/lua-5.1/src/loadlib.c:76:21: warning: ISO C forbids conversion of object pointer to function pointer type [-pedantic]

but that's fine since the systems in question are POSIX.  But I was quite
surprised when I did:

	make CFLAGS="-O3 -DNDEBUG -pg" LDFLAGS="-pg"	# -pg for profiling

and got the NDEBUG redefined warning.  It doesn't hurt (it's a warning) but
it was rather unexpected.  In production, the code is compiled as

	make -j CFLAGS="-O2 -DNDEBUG"

There's rarely ever a problem with compiling the code for production (we use
Jenkins) and because of that, I never saw the issue (which isn't much of an
issue).

  I'm just found it unsettling.  I tend to think of NDEBUG as soemthing to
be set by the build process, not in a C source file.

  -spc