I've tried "-U__GNUC__", but the preprocessor's output still contains "__attribute__" or something like that. How to make the compiler discard those non-standard things? My OS is OS X 10.10 and when I run the compiler with option "-U__GNUC__", it complains:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/cdefs.h:81:2:
warning:
"Unsupported compiler detected" [-W#warnings]
#warning "Unsupported compiler detected"
You probably cannot do that.
You might try to compile with clang -std=c11 -pedantic-errors -Wall -Wextra -Werrors; see here; this should prohibit __attribute__ in your user code, but still allow it in system headers.
Notice that according to standards, identifiers starting with _ are implementation reserved and should not be used in standard conforming application code.
Hence your implementation (e.g. standard C or standard C++ library) can (and probably does) use them. And several __attribute__-s in system headers are useful for the optimizations done by the compiler e.g. the compiler can optimize your use of malloc because system headers probably declare malloc with __attribute__((malloc)), etc.
Related
Let's assume the following code
int __foo(void) {
return 0;
}
int _BAR(void) {
return 3;
}
int main(void) {
return __foo() & _BAR();
}
Double underscore and a single underscore followed by an uppercase letter symbols are reserved and therefore not allowed (This is a C++ question, but it also mentions the C rules).
I tried -Wall -Wextra -pedantic options on gcc and -Weverything option on clang, both do not warn about this.
Is there any way to enable a compiler warning for this?
GCC and Clang appear not to offer such a feature.
The documentation for GCC warning messages is here (for version 8.2; to seek documentation for other versions, start here). None of them mention checking for reserved identifiers or identifiers that begin with an underscore followed by an underscore or capital letter, except certain special cases (such as the built-in __FILE__) that are not useful for this question.
Clang’s documentation is here (that appears to be a link for the current version, so expected it to be updated in the future). It similarly has no mention of checking for reserved identifiers.
In Clang, -Weverything enables all diagnostics, so, if no diagnostic appears when compiling sample code with -Weverything, the desired diagnostic is not implemented in Clang.
There does not appear to be any reason a compiler cannot do this. Clang does track where source text originates. For example, if macro expansions result in a syntax error, Clang prints multiple diagnostic lines showing the names, line numbers, and file names of the macros involved. Furthermore, Clang suppresses warnings in system headers and can be told to treat additional files (such as headers for libraries) similarly with #pragma clang system_header. So it seems feasible for Clang to produce a warning for any reserved identifier that does not originate in a system header. The lack of such a feature may be due to lack of demand.
A compiler can't practically warn you of this. Once the preprocessor has included any standard library files (which can of course contain double underscores), the compiler doesn't really know the origins of such code.
A good IDE or static analyser can warn you however.
I studied Option Summary for gfortran but found no compiler option to detect integer overflow. Then I found the GCC (GNU Compiler Collection) flag option -fsanitize=signed-integer-overflow here and used it when invoking gfortran. It works--integer overflow can be detected at run time!
So what does -fsanitize=signed-integer-overflow do here? Just adding to the machine code generated by gfortran some machine-level pieces that check integer overflow?
What is the relation between GCC (GNU Compiler Collection) flag options and gfortran compiler options ? What gcc compiler options can I use for gfortran, g++ etc ?
There is the GCC - GNU Compiler Collection. It shares the common backend and middleend and has frontends for different languages. For example frontends for C, C++ and Fortran which are usually invoked by commands gcc, g++ and gfortran.
It is actually more complicated, you can call gcc on a Fortran source and gfortran on a C source and it will work almost the same with the exceptions of libraries being linked (there are some other fine points). The appropriate frontend will be called based on the file extension or the language requested.
You can look almost all GCC (not just gcc) flags for all of the mentioned frontends. There are certain flags which are language specific. Normally you will get a warning like
gfortran -fcheck=all source.c
cc1: warning: command line option ‘-fcheck=all’ is valid for Fortran but not for C
but the file will compile fine, the option is just ignored and you will get a warning about that. Notice it is a C file and it is compiled by the gfortran command just fine.
The sanitization options are AFAIK not that language specific and work for multiple languages implemented in GCC, maybe with some exceptions for some obviously language specific checks. Especially -fsanitize=signed-integer-overflow which you ask about works perfectly fine for both C and C++. Signed integer overwlow is undefined behaviour in C and C++ and it is not allowed by the Fortran standard (which effectively means the same, Fortran just uses different words).
This isn't a terribly precise answer to your question, but an aha! moment, when learning about compilers, is learning that gcc (the GNU Compiler Collection), like llvm, is an example of a three-stage compiler.
The ‘front end’ parses the syntax of whichever language you're interested, and spits out an Abstract Syntax Tree (AST), which represents your program in a language-independent way.
Then the ‘middle end’ (terrible name, but ‘the clever bit’) reorganises that AST into another AST which is semantically equivalent but easier to turn into machine code.
Then the ‘back end’ turns that reorganised AST into assembler for one-or-other processor, possibly doing platform-specific micro-optimisations along the way.
That's why the (huge number of) gcc/llvm options are unexpectedly common to (apparently wildly) different languages. A few of the options are specific to C, or Fortran, or Objective-C, or whatever, but the majority of them (probably) are concerned with the middle and last bits, and so are common to all of the languages that gcc/llvm supports.
Thus the various options are specific to stage 1, 2 or 3, but may not be conveniently labelled as such; with this in mind, however, you might reasonably intuit what is and isn't relevant to the particular language you're interested in.
(It's for this sort of reason that I will dogmatically claim that CC++FortranJavaPerlPython is essentially a single language, with only trivial syntactical and library minutiae to distinguish between dialects).
with gcc using -std=gnu99, the following code compiles:
void f()
{
struct X data = {};
// do something with data
}
Is this valid C ?
Is this a gnu extension ?
How can I tell gcc to not accept this kind of init ?
I want to ensure compatibility with other compilers (like visual 2015 for example)
If you want to reject code containing GNU-specific extensions, use -std=c99 -pedantic-errors (-pedantic will issue diagnostics for non-standard extensions, but it won't necessarily reject the code outright). However, if you want to guarantee ISO conformance, be aware that this isn't a 100% solution. From the gcc man page:
Some users try to use -pedantic 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 -pedantic. We don't have plans to support such a feature in the near future.
The -pedantic option will cause a warning to be displayed in this case, and -Werror will cause all warnings to be treated as errors.
For example:
x1.c: In function ‘f’:
x1.c:11:19: error: ISO C forbids empty initializer braces [-Werror=pedantic]
struct X data = {};
No, the empty initializer is not standard C. It is a gcc extension. See this for a detailed description.
By specifying -std=gnu99, you allowed the GNU extensions to be used. You can force the compiler to only allow the standard conforming code, by specifying -std=cXX option.
From the gcc online manual (emphasis mine)
-std=
The compiler can accept several base standards, such as ‘c90’ or ‘c++98’, and GNU dialects of those standards, such as ‘gnu90’ or ‘gnu++98’. When a base standard is specified, the compiler accepts all programs following that standard plus those using GNU extensions that do not contradict it. For example, -std=c90 turns off certain features of GCC that are incompatible with ISO C90, such as the asm and typeof keywords, but not other GNU extensions that do not have a meaning in ISO C90, such as omitting the middle term of a ?: expression. On the other hand, when a GNU dialect of a standard is specified, all features supported by the compiler are enabled, even when those features change the meaning of the base standard. As a result, some strict-conforming programs may be rejected. The particular standard is used by -Wpedantic to identify which features are GNU extensions given that version of the standard. For example -std=gnu90 -Wpedantic warns about C++ style ‘//’ comments, while -std=gnu99 -Wpedantic does not.
Is there any way to compile C code with c89 standard NOT c99 in Xcode (or another way with terminal)?
I've searched in Xcode settings but I didn't find any way to choose compiler or standard.
You should add -pedantic-errors to Other C flags in your project settings, like so:
Of course, don't forget to set the C language dialect to C89 as well.
This will give you the appropriate compile time errors when you try to compile something that is not valid C89.
Optionally, if you want Xcode to compile your code regardless of incompatibilities, but only give you yellow warnings at the problematic lines, use -pedantic instead of -pedantic-errors.
In a nutshell, these flags make the compiler stick to the language standard more strictly, as opposed to the default behavior, which is to attempt compiling the code any way possible.
I hope this helps :)
Source
(even though they mention this in the context of GCC, but the same flags apply for Clang as well)
This code does not compile for me on GCC version 4.3.2 (Debian 4.3.2-1.1)
main() {
int unix;
}
I've checked the C keywords list and "unix" is not one of them.
Why am I getting the following error?
unix.c:2: error: expected identifier or ‘(’ before numeric constant
unix is not a identifier reserved by the Standard.
If you compile with -std=c89 or -std=c99 the gcc compiler will accept the program as you expected.
From gcc manual ( https://gcc.gnu.org/onlinedocs/cpp/System-specific-Predefined-Macros.html ), the emphasis is mine.
... However,
historically system-specific macros
have had names with no special prefix;
for instance, it is common to find
unix defined on Unix systems. For all
such macros, GCC provides a parallel
macro with two underscores added at
the beginning and the end. If unix is
defined, __unix__ will be defined too.
There will never be more than two
underscores; the parallel of _mips is
__mips__.
unix is one of the defines the preprocessor uses in gcc
to get a list of defs use
gcc -dM -E -x c /dev/null
(-dM tells gcc to debugdump the defs -E tells it to stop after prepreocessing and -x c /dev/null tells him to pretend /dev/null is a c file)
Run your code through the preprocessor to find out what the compiler is actually seeing:
gcc -E unix.c
Then see if your variable unix is preserved or converted by the preprocessor.
It is not a keyword.
It is a predefined macro to identify the type of system. On Unix and Unix like systems it is defined to be 1.
To disable this use the -ansi option:
In C mode, this is equivalent to -std=c89. In C++ mode, it is equivalent to -std=c++98.
This turns off certain features of GCC that are incompatible with ISO C90 (when compiling C code), or of standard C++ (when compiling C++ code), such as the "asm" and "typeof" keywords, and predefined macros such as "unix" and "vax" that identify the type of system you are using. It also enables the undesirable and rarely used ISO trigraph feature. For the C compiler, it disables recognition of C++ style // comments as well as the "inline" keyword.
I'm gona take a wild stab at this and guess that gcc effectively #defined unix as 1 on UNIX systems.
try
main(){
printf("%d", unix);
}
and see what you get.
To answer your question, no unix is not a reserved word in C.
However, the symbol unix is most likely defined by the preprocessor either because you include a header file or because the compiler defines it.