Red Hat Bugzilla – Bug 99474
gcc -std=c89 should not allow inline declarations (regression from gcc 2.96)
Last modified: 2007-04-18 12:55:46 EDT
Description of problem:
In the C89 standard, declarations may not follow statements:
int x = 1;
The above is legal in C++, and I believe it is legal in C99,
but it is not legal in C89.
In order to keep my code portable amongst various compilers
on various architectures, including non-gcc compilers, I want
the compiler to issue an error when it encounters any code that
is not legal in C89.
With gcc 2.96 20000731 (Red Hat Linux 7.2) I was able to do that
with these arguments:
That disallowed // comments and post-statement declarations,
and all was good.
With gcc 3.2.2 20030222 (Red Hat Linux 9) this no longer works:
with those arguments, post-statement declarations are silently
allowed, resulting in un-flagged unportable code.
Please fix this -std=c89 to allow *only* those features that are
a part of the C89 standard. (The -std=gnu89 arguement already
exists to indicate "C89 plus non-standard extensions.")
Version-Release number of selected component (if applicable):
Guess you missed -std=c89 -pedantic (or even -std=c89 -pedantic-errors) in
gcc command line switches documentation:
"To select this
standard in GCC, use one of the options `-ansi', `-std=c89' or
`-std=iso9899:1990'; to obtain all the diagnostics required by the
standard, you should also specify `-pedantic' (or `-pedantic-errors' if
you want them to be errors rather than warnings)."
That's not the same thing.
gcc3 "-std=c89 -pedantic" produces a zillion more errors/warnings than
gcc2 "-std=c89" did.
I really just want the gcc2 behavior back. Why do you think that's a
I have no problems with the current behaviour, if you want to write standard
compliant code, -pedantic* is a must, if you don't, you accept there are some extensions
allowed or that you don't get diagnostic everywhere where required.
There is no -std=gnu89gcc29x mode which would be the language dialect
accepted by gcc 2.9x -std=gnu89.
If you want to argue about this, please do so either in gcc.gnu.org bugzilla
or on email@example.com mailing list. If it gets changed upstream we will
change accordinly of course.