[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lua 5.3.0 (rc3) now available
- From: William Ahern <william@...>
- Date: Mon, 5 Jan 2015 16:15:16 -0800
On Mon, Jan 05, 2015 at 06:09:10PM -0500, Sean Conner wrote:
> It was thus said that the Great Lorenzo Donati once stated:
> >
> >
> > On 05/01/2015 12:01, Roberto Ierusalimschy wrote:
> > >>Update: I also ran the the test suite (with _U=true) and everything was
> > >>fine. So it seems that those warnings don't imply something went
> > >>horribly wrong.
> > >
> > >Thanks. Hopefuly the warnings will go away changing -std=c99 to
> > >-std=gnu99. (This change seems to be safe to all platforms that are
> > >using -std=c99 now.)
> > >
> >
> > I don't know the differences between the two compiler modes, but doesn't
> > this risk of opening the way for non-conformance "bugs" in the future?
> > Maybe a non-C99 GNU GCC feature could slip in and go undetected, or am I
> > missing something?
>
> The major difference, as far as I can tell, is that "-std=gnu99" defines
> _GNU_SOURCE and allows some GNU extentions that aren't legal C99. If you
> use "-std=c99" and define _GNU_SOURCE, the warnings go away (that's how I
> typically compile my C code under Linux).
>
As somebody else mentioned, on Linux gcc -std=c99 will set __STRICT_ANSI__.
On the other hand, -std=gnu99 doesn't set _GNU_SOURCE, it just _doesn't_ set
__STRICT_ANSI__. Proof:
$ for STD in gnu99 c99; do \
echo "" | gcc -std=${STD} -E - -dM > /tmp/${STD}.txt; \
done;
$ diff -u0 /tmp/c99.txt /tmp/gnu99.txt
--- /tmp/c99.txt 2015-01-05 15:55:54.704859905 -0800
+++ /tmp/gnu99.txt 2015-01-05 15:55:54.692859953 -0800
@@ -55,0 +56 @@
+#define __STDC_UTF_16__ 1
@@ -75 +75,0 @@
-#define __STRICT_ANSI__ 1
@@ -116,0 +117 @@
+#define unix 1
@@ -156,0 +158 @@
+#define linux 1
@@ -200,0 +203 @@
+#define __STDC_UTF_32__ 1
__STRICT_ANSI__, in the absence of other feature macros, causes glibc to
hide all macro definitions and prototypes not defined by ISO C, including
popen. AFAICT it has little if anything to do with compiler extensions.
And at least in my tests -std=c99 doesn't by itself cause GCC to warn about
non-C99 constructs. You need to specify -pedantic for it to complain, in
which case it will complain whether you specify -std=c99 or -std=gnu99. Proof:
int main(void) {
struct x {
union { int i; int j; }; /* C11 extension */
int a[0]; /* GCC extension */
} *x = 0;
(void)x;
return 0;
}
$ gcc --version | head -n1
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
$ gcc -o test test.c -std=c99 -Wall -Wextra
$ gcc -o test test.c -std=gnu99 -Wall -Wextra
$ gcc -o test test.c -std=gnu99 -Wall -Wextra -pedantic
test.c: In function 'main':
test.c:3:30: warning: ISO C99 doesn't support unnamed structs/unions
[-Wpedantic]
union { int i; int j; }; /* C11 extension */
^
test.c:4:11: warning: ISO C forbids zero-size array 'a' [-Wpedantic]
int a[0]; /* GCC extension */
^
FWIW, glibc 2.19 added a new feature macro, _DEFAULT_SOURCE. If all you want
is the latest POSIX personality, plus historical BSD and SysV extensions,
that's the one to use. But older verisons of glibc don't understand it, so
we're kind of stuck using _GNU_SOURCE.