As you can see in the following code, I've introduced a nested function within main():
#include <stdio.h>
int main(){
int a=5;
printf("%d\n",a);
{
int a=10;
printf("%d\n",a);
}
printf("%d\n",a);
//Nested function
int main(int a){
if(a>0)printf("%d\n",a--);
return 0;
}
main(7);
return 0;
}
As far as I could understand I used the -std=c99 flag in gcc to "disable" the unnecessary extensions, but I did not get any error.
gcc temp3.c -std=c99 -o temp3.out
Where have I made the mistake?
Add -pedantic and -Werror to the command line.
Using GCC 6.1.0 on Mac OS X 10.11.6, with your original code in a file ped73.c and my default compilation options, I get:
$ gcc -O3 -g -std=c11 -Wall -Wextra -Werror -Wmissing-prototypes -Wstrict-prototypes \
> -Wold-style-definition ped73.c -o ped73
ped73.c:3:5: error: function declaration isn’t a prototype [-Werror=strict-prototypes]
int main(){
^~~~
ped73.c: In function ‘main’:
ped73.c:3:5: error: old-style function definition [-Werror=old-style-definition]
ped73.c:13:6: error: ‘main’ takes only zero or two arguments [-Werror=main]
int main(int a){
^~~~
ped73.c:13:6: error: ‘main’ is normally a non-static function [-Werror=main]
$
Renaming the nested function to nested and using int main(void), I get:
$ gcc -O3 -g-std=c11 -Wall -Wextra -Werror -Wmissing-prototypes -Wstrict-prototypes
> -Wold-style-definition -o ped73
$
Using the extra option -pedantic I get:
$ gcc -O3 -g -std=c11 -Wall -Wextra -Werror -Wmissing-prototypes -Wstrict-prototypes \
> -Wold-style-definition -pedantic ped73.c -o ped73
ped73.c: In function ‘main’:
ped73.c:13:2: error: ISO C forbids nested functions [-Werror=pedantic]
int nested(int a){
^~~
cc1: all warnings being treated as errors
$
Then what's the point of -std=c99?
The -std=c99 flag disables the GNU extensions that GCC thinks should be disabled — such as POSIX versions, etc. See C Dialect Options for the meaning of -std=; see Warning Options for the meaning of -pedantic.
-Wpedantic
-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++. For ISO C, follows the version of the ISO C standard specified by any -std option used.
Valid ISO C and ISO C++ programs should compile properly with or without this option (though a rare few require -ansi or a -std option specifying the required version of ISO C). However, without this option, certain GNU extensions and traditional C and C++ features are supported as well. With this option, they are rejected.
-Wpedantic does not cause warning messages for use of the alternate keywords whose names begin and end with __. Pedantic warnings are also disabled in the expression that follows __extension__. However, only system header files should use these escape routes; application programs should avoid them. See Alternate Keywords.
Some users try to use -Wpedantic to check programs for strict ISO C conformance. They soon find that it does not do quite what they want: it finds some non-ISO practices, but not all—only those for which ISO C requires a diagnostic, and some others for which diagnostics have been added.
A feature to report any failure to conform to ISO C might be useful in some instances, but would require considerable additional work and would be quite different from -Wpedantic. We don't have plans to support such a feature in the near future.
Where the standard specified with -std represents a GNU extended dialect of C, such as ‘gnu90’ or ‘gnu99’, there is a corresponding base standard, the version of ISO C on which the GNU extended dialect is based. Warnings from -Wpedantic are given where they are required by the base standard. (It does not make sense for such warnings to be given only for features not in the specified GNU C dialect, since by definition the GNU dialects of C include all features the compiler supports with the given option, and there would be nothing to warn about.)
And there's also a different option that gives pedantic errors:
-pedantic-errors
Give an error whenever the base standard (see -Wpedantic) requires a diagnostic, in some cases where there is undefined behavior at compile-time and in some other cases that do not prevent compilation of programs that are valid according to the standard. This is not equivalent to -Werror=pedantic, since there are errors enabled by this option and not enabled by the latter and vice versa.
There are multiple questions about which GCC compiler options to use, including:
Recommended gcc warning options for C
What is the purpos of using -pedantic in GCC/G++ compiler
warning: implicit declaration of function when compiling C source
and no doubt there are many others that could be added to that list. Basically, the default options I use ensure that functions are declared before they are used (or, are defined as a static function before they are used), and that the function declarations have full prototypes — no empty parentheses () — and use the -Wall and -Wextra to spot a number of other routine problems, including mismatches between format strings and arguments to the printf() and scanf() families of functions.
Related
A function, before being used, needs to be declared either in a included header or otherwise (though not a good practice). The header file describes the functions and variables that may be found in a library or an object file and the compiler can create (as of yet) unreferenced symbols to be resolved later whilst linking.
However, my compiler (gcc based toolchain called esp-open-sdk (xtensa CPU)) continues despite finding no reference to a function in the headers and only in the linking stage does the linker intimate of an `undefined reference to <-function-name->'.
Another strange behaviour is that the compiler says nothing if there is no return statement, and the function is not "void".
My question is: What is causing this behaviour? I think it's unlikely but is it some compiler flag?
My compiler flags are:
CFLAGS = -Os -g -O2 -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -D__ets__ -DICACHE_FLASH
and the linker flags are:
LDFLAGS = -nostdlib -Wl,--no-check-sections -u call_user_start -Wl,-static
Probably you use an old version of gcc. Before version 5.x, gcc defaults to a non-standard called "gnu90", which is a non-standard version of the obsolete C90 standard. There is no reason to ever use gnu90 unless you are maintaining some old Linux code. To avoid this, compile with:
-std=c11 -pedantic-errors
-std=c11 meaning you want the compiler to use the current C standard, without involving gnus or other strange animals. -pedantic-errors means that you want it to actually follow the standard and not just pretend to do it.
In order to get the warning for no return from functions, you need to use the option -Wreturn-type, which is included by using -Wall. Always compile with
-Wall -Wextra
Note that "Wall" does not stand for "all warnings", as it leads you to believe. Rather, -Wall means a fistful of warnings and -Wextra means a few warnings more.
I was coding on my project when I discovered that the anonymous structs I've been using for a while are actually only available in C11, not C99, the standard I want to code against.
Given the following code:
struct data {
int a;
struct {
int b;
int c;
};
};
int main()
{
struct data d;
d.a = 0;
d.b = 1;
d.c = 2;
return 0;
}
This code should only compile in C11 (or if compiler extensions provide this feature and are enabled). So let's see the results on different compilers:
clang 5
compiler:
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
command:
clang -std=c99 -Wall test.c -o test
result:
**OK**
gcc 4.1
compiler:
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54)
command:
gcc -std=c99 -Wall test.c -o test
result:
**NOT OK**
test.c:6: warning: declaration does not declare anything
test.c: In function 'main':
test.c:14: error: 'struct data' has no member named 'b'
test.c:15: error: 'struct data' has no member named 'c'
gcc 4.7
compiler:
gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8)
command:
gcc -std=c99 -Wall test.c -o test
result:
**OK**
test.c: In function 'main':
test.c:11:14: warning: variable 'd' set but not used [-Wunused-but-set-variable]
I've always tried to force the compiler to C99 mode by specifying -std=c99, but obviously this doesn't work (except for gcc 4.1 which compiles fine without the -std parameter).
So my question is now, how can I force the compilers gcc and clang, in any version, to issue an error if I write code that does not conform to the standard I specify using -std? Is there some command line argument that I don't know of?
-std=c99 won't disable language extensions (GNU C has anon structs in C99).
The -pedantic (or -pedantic-errors) flags make the compiler warn on language extensions.
Both gcc and clang allow a large number of extension and here for clang. clang in general attempts to support most of the extensions that gcc does. Both will even allow you to use features that are C only in C++ for example VLAs which are a C99 feature.
In this case both are allowing you to use Unnamed struct/union fields within structs/unions in C99 mode even though it is a C11 feature.
The Language Standards Supported by GCC documents well what flags are required to turn these into warnings and errors and as far as I know clang follows the same conventions:
[...]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). [...]
So -pedantic will warn you if you are using an extension and -pedantic-errors will turn these warnings into an error. With -pedantic flag you should see a warning like this in gcc:
warning: ISO C99 doesn't support unnamed structs/unions [-Wpedantic]
and this in clang (see it live):
warning: anonymous structs are a C11 extension [-Wc11-extensions]
and it turn into an error with -pedantic-errors.
When compiling something as simple as
inline int test() { return 3; }
int main()
{
test();
return 0;
}
with gcc -c test.c, everything goes fine. If the -ansi keyword added, gcc -ansi -c test.c, one gets the error message
test.c:1:8: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘int’
This is true even if the C99 standard is explicitly selected, gcc -std=c99 -ansi -c test.c.
What is the reason for this, and is there a recommended fix?
You need to use:
gcc -std=c99 -c test.c
The -ansi flag specifies c90:
The -ansi option is equivalent to -std=c90.
ANSI C was effectively the 1990 version of C, which didn't include the inline keyword.
Nope, ANSI C doesn't have inline.
Your second command actually overrides -std=c99 with -ansi (they both affect -std=), so you are in effect compiling using ANSI C (no C99).
The inline keyword is not part of the original ANSI C standard
(C89) so the library does not export any inline function definitions
by default. Inline functions were introduced officially in the newer
C99 standard but most C89 compilers have also included inline as an
extension for a long time.
quoted from Gnu website
The reason it works fine without the ansi option at all is because gcc defaults to '-std=gnu90', which is ANSI/C89 plus extensions (one of which, not surprisingly, is support for inline functions). If you just want ANSI C support you don't need any options, unless you want strict standard compliance (which obviously may be useful if your code is going to be compiled on other compilers).
This question already has answers here:
Recommended GCC warning options for C [closed]
(15 answers)
Closed 8 years ago.
What GCC options should be set to have GCC as strict as possible? (and I do mean as strict as possible) I'm writing in C89 and want my code to be ANSI/ISO compliant.
I'd recommend using:
-Wall -Wextra -std=c89 -pedantic -Wmissing-prototypes -Wstrict-prototypes \
-Wold-style-definition
You should compile with -O as well as -g as some warnings are only available when the optimizer is used (actually, I usually use -O3 for spotting the problems). You might prefer -std=gnu89 as that disables fewer extensions in the libraries. OTOH, if you're coding to strict ANSI C89, maybe you want them disabled. The -ansi option is equivalent to -std=c89 but not quite as explicit or flexible.
The missing prototypes warns you about functions which are used (or external functions defined) without a prototype in scope. The strict prototypes means you can't use 'empty parentheses' for function declarations or definitions (or function pointers); you either need (void) or the correct argument list. The old style definition spots K&R style function definitions, such as:
int old_style(a, b) int a; double b; { ... }
If you're lucky, you won't need to worry about that. I'm not so lucky at work, and I can't use strict prototypes, much to my chagrin, because there are too many sloppy function pointers around.
See also: What is the best command-line tool to clean up code
This set of options is pretty good:
-Wall -Wextra -ansi -pedantic
You'll have to read the documentation to see if there are any extra warnings getting left out by that combination.
You should be warned that strict C89 doesn't include support for // style comments, and there are some pretty serious restrictions on the number of significant characters in the names of objects with external linkage.
Are Statement and Declarations in Expressions specific to GNU C ? Or this feature is also included in C99 standard ?
It's a GCC extension. (See the GCC docs, e.g. here for gcc 4.3.3, for a full list of GCC extensions; and the C99 spec is available here.)
GCC will warn about such things if you use the -pedantic -std=c99 flags, e.g.:
$ cat foo.c
int main(void)
{
return ({ int a = 0; a; });
}
$ gcc -pedantic -std=c99 -c foo.c
foo.c: In function 'main':
foo.c:3: warning: ISO C forbids braced-groups within expressions
While this is not a C99 standard, this extension is not specific to gcc either.
For instance, the clang compiler and Intel C++ compiler support this extension.
It's a GNU C extension. That's what they mean by "may appear ... in GNU C." (my emphasis)