Re: Warnings compiling LPeg
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Warnings compiling LPeg
- From: Sean Conner <sean@...>
- Date: 2017年2月22日 15:07:23 -0500
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