What is the version of C used in GCC? C99, C11 or C90? I thought was the GCC use C99 but I was mistaken:
for(int i = 0; i < 100; i++){
...
}
error: ‘for’ loop initial declarations are only allowed in C99 mode.
According to 2 Language Standards Supported by GCC:
The default, if no C language dialect options are given, is -std=gnu90; this is intended to change to -std=gnu11 in some future release.
I believe the default is -std=gnu90. You could specify -std=c99 in your compiler flag to support this.
By default gcc uses C90 with GNU extension, this is all covered in the gcc docs Language Standards Supported by GCC, the flag for this would be -std=gnu90:
The default, if no C language dialect options are given, is -std=gnu90; this is intended to change to -std=gnu11 in some future release.
If you want C99 support than you should use -std=c99, although this does not mean gcc will not use extensions, so if you want to receive a warning when gcc using an extension you need to add -pedantic and -pedantic-errors to turn that into an error:
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)
Use -std=99
Before C99, you had to define the local variables at the start of a block. C99 imported the C++ feature that you can intermix local variable definitions with the instructions and you can define variables in the for and while control expressions.
Related
Given that I know the compiler version:
ANSI C 5.3.0 - GNU C Compiler with options: -lm -lcrypt -O2 -pipe -ansi -DONLINE_JUDGE
How can I know which C standard(C89, C99, C11, C17/18) it adopted If I want to write C program that strictly follows the standard?
How can I know which C standard(C89, C99, C11, C17/18) it adopted
-ansi doesn't mean "give me standard C". It means "give me dinosaur C" and is 100% equivalent to using -std=c89. So if you compiled with -ansi, you are using C89, period.
If you don't use -ansi or -std=... options, then gcc defaults to these versions:
gcc before version 5.0.0 defaults to gnu90.
gcc between version 5.0.0 and up to < 8.0.0 defaults to gnu11.
gcc from 8.0.0 defaults to gnu17.
"gnu" being the C standard + non-standard extensions, in the above cases corresponding to C90, C11 and C17 respectively.
"gnu" mode is not strictly following the standard. In order to do that, you must compile with -std=cxx where xx is your desired version of C. This restricts gcc to a subset only containing standard C features.
But in order to actually make it strict when it comes to reporting compiler errors for invalid use of C, you must do -std=cxx -pedantic-errors.
gcc has a flag that lets you specify the version of the C standard to compile against.
-std=c89 for C89
-std=c99 for C99
-std=c11 for C11
The version you have probably doesn't have support for C17.
There's also:
-std=gnu89 for C89 with GNU extensions
-std=gnu99 for C99 with GNU extensions
-std=gnu11 for C11 with GNU extensions
I do include<stdlib.h> where qsort_r is given. And I use gcc -std=c99 -O3 myfun.c -o myfun to compile.
It compiles, links and runs well. I don't know why I got this warning and what is potential risk of this warning ?
BTW, my compiler is gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
It does so because you use -std=c99 , there's no qsort_r function in stdlib.h in c99.
Use -std=gnu99 to make the extensions available, or add a #define _GNU_SOURCE to your source files before including the header files.
qsort_r is not supported by C99. Specification says nothing about it.
Language Standards Supported by GCC:
By default, GCC provides some extensions to the C language that on rare occasions conflict with the C standard1. See Extensions to the C Language Family. Use of the -std options listed above will disable these extensions where they conflict with the C standard version selected. You may also select an extended version of the C language explicitly with -std=gnu89 (for C89 with GNU extensions) or -std=gnu99 (for C99 with GNU extensions). The default, if no C language dialect options are given, is -std=gnu89; this will change to -std=gnu99 in some future release when the C99 support is complete. Some features that are part of the C99 standard are accepted as extensions in C89 mode.
1. Emphasis is mine
I am using gcc (Ubuntu 4.4.1-4ubuntu9) to compile a program that I'm writing, but it seems to vomit whenever it sees a // comment in my code, saying:
interface.c :##: error: expected expression before â/â token<
Does the gcc compile mode I'm using forbid // comments?
$ gcc -g -ansi -pedantic interface.c structs.h -c -I. -I/home/me/project/h
Why?
// comments are not allowed in old (pre 99) C versions, use /**/ (or remove the -ansi, that is a synonym for the C89 standard)
See C++ comments in GNU compiler documentation.
In GNU C, you may use C++ style comments, which start with // and continue until the end of the line. Many other C implementations allow such comments, and they are included in the 1999 C standard. However, C++ style comments are not recognized if you specify an -std option specifying a version of ISO C before C99, or -ansi (equivalent to -std=c89).
(Emphasis is mine because some of the posts claim that // are not allowed in standard C whereas that is only true for pre-99 standards).
What gcc options shall I use to enforce ANSI C (C99) warnings/errors?
gcc (GCC) 3.4.2 (mingw-special)
I'm using:
gcc -pedantic -ansi -std=c99
is this correct?
The -ansi flag is synonymous with the -std=c89 flag.
Just using -std=c99 with -pedantic should be sufficient.
When in doubt, you can always refer to the GCC documentation. As of GCC 3.4.2, the chapter to read is 2 - Language Standards Supported by GCC.
This is an old question but I just wanted to add some extra points.
Firstly, regardless of the set of generic command-line switches you supply to GCC, currently it doesn't appear to be possible to make GCC to report all constraint violations as "errors" and everything else as "warnings". Some of the diagnostic messages GCC reports as "warnings" are in fact constraint violations (i.e. "errors") from the point of view of C language, but there's no way to force GCC to recognize that fact and generate an "error" diagnostic. Quite possibly that a more precise separation can be achieved by fine-tuning individual warning types, but I'm not sure GCC settings provide sufficient granularity to achieve a good match.
Secondly, GCC provides -pedantic-errors option that can be used in place of plain -pedantic, which is intended to enable a more precise (as described above) classification of diagnostic messages into "errors" and "warnings". It is still not perfect though.
P.S. The language specification doesn't require/define the separation of diagnostic messages into "errors" and "warnings", but in practice many programmers expect constraint violations to be reported as "errors". I thought that you might have meant something like that when you mentioned "enforcing warnings/errors" in your question.
-ansi
In C mode, this is equivalent to -std=c89. In C++ mode, it is equivalent to -std=c++98.
ANSI C isn't the same as C99 (yet). Also, -Wall might also be of interest, but only -pedantic should do what you want.
I have the following C code:
#include <math.h>
int main(int argc, char ** argv)
{
double mydouble = 100.0;
double whatever = round(mydouble);
return (int) whatever;
}
When I compile this, I get the warnings:
round_test.c: In function ‘main’:
round_test.c:6: warning: implicit declaration of function ‘round’
round_test.c:6: warning: incompatible implicit declaration of built-in function ‘round’
I'm rusty with C, but I thought that the #include brought a declaration for round() into scope. I've checked my ANSI standard (C99 is the only copy I have) which confirms that the round() function exists in the math.h header. What am I missing here?
Edit: The compiler is GCC 4.3.2 on Ubuntu (intrepid, IIRC). Running gcc -E gives:
$ gcc -E round_test.c | grep round
# 1 "round_test.c"
# 1 "round_test.c"
# 2 "round_test.c" 2
double whatever = round(mydouble);
so the definition obviously isn't being found in the headers.
I see you're using gcc.
By default, gcc uses a standard similar to C89. You may want to "force" it to use the C99 standard (the parts it complies with)
gcc -std=c99 -pedantic ...
Quote from GCC Manual
By default, GCC provides some
extensions to the C language that on
rare occasions conflict with the C
standard. See Extensions to the C
Language Family. Use of the -std
options listed above will disable
these extensions where they conflict
with the C standard version selected.
You may also select an extended
version of the C language explicitly
with -std=gnu89 (for C89 with GNU
extensions) or -std=gnu99 (for C99
with GNU extensions). The default, if
no C language dialect options are
given, is -std=gnu89; this will change
to -std=gnu99 in some future release
when the C99 support is complete. Some
features that are part of the C99
standard are accepted as extensions in
C89 mode.
Something must be wrong with your gcc installation, system headers, or compilation options.
Try compiling with -E. That will show you what the preprocessor output -- including which headers are being included and what's in them. On my Ubuntu Linux system it's about 1000 lines of output, including this:
extern double round (double __x) __attribute__ ((__nothrow__)) __attribute__ ((__const__));
You need to tell gcc that you want C99, and that you want to link in libm:
gcc -std=c99 -lm round_test.c
The code you type compiles cleanly on MacOS X 10.5.8 with GCC 4.0.1. If prodded with options '-Wall -Wextra', it complains about unused parameters argc and argv - not material.
Have you looked in <math.h> on your machine?
Have you tried with options such as '-stc=c99'?
C99 was the answer, but the full story is a little more complicated. The reason I'd been playing with this at all was that I was trying to compile a library written for Windows, which had its own "optimised" definition of round(). I got a linker error telling me that the definition conflicted with the built-in, so I removed the definition (and declaration). Once I'd done that I started to get the "implicit declaration error".
It seems that the default compile mode (without the -std=c99 flag) is neither conforming C89 nor C99: if it were conforming C89, you should be able to provide a custom definition of round() without conflicting, and if it were conforming C99 the declaration should be in math.h.
you need to link with the math library. So when you compile, be sure to add the -lm flag.