I found out that structures without any named members (and without any members in particular, as I understood) invoke UB in C. Only GNU GCC supports such structures as an extension. I've tried to create a piece of code which will behave differently when compiled using GCC vs. Clang but with no success. I'm wondering if there is a C program that if you compile it via Clang, it will work differently than if it was compiled using GCC. The opposite option, in a nutshell, is that Clang also supports empty structures but this is not mentioned in documentation.
Literally the only thing I could find in clang's documentation is some info about a warning -Wgnu-empty-struct, which will be activated in -pedantic mode. So the compiler clearly supports GNU empty structs.
As for where to find the clang documentation regarding how empty structs should be used, what they are good for and under which language standards they are valid, I have no idea.
For completeness, as Lundin wrote, empty structs are supported in Clang.
I'm wondering if there is a C program that if you compile it via Clang, it will work differently than if it was compiled using GCC. The opposite option, in a nutshell, is that Clang also supports empty structures but this is not mentioned in documentation.
Undefined behavior means that it's undefined. The clang compiler is allowed to produce binary code as gcc even if it does not support empty structs. Be very careful to draw conclusions strictly from behavior.
Related
I am trying to compile a C source code to a machine code using an ubunto terminal
My tutor instruction was to use the following command:
running clang myprogramm.c -std=c11
Why shall I use the keyword -std=c11 and what is the difference to using just
clang myprogramm.c
Using std= options is required by your tutor (I'm divinig her motives, I'm particularly good at this!) because she wants to make sure you stay away from all those nifty Clang features that turn the accepted language from C to A LANGUAGE SUPERFICIALLY LOOKING LIKE C BUT ACTUALLY A DIFFERENT LANGUAGE NOT SUPPORTED BY OTHER C COMPILERS.
That is more than just additional library functions. It include syntax changes that break the grammar of Standard C, as defined by ISO. A grasshopper should not use these while learning. Using -std=c11 makes sure Clang either warns about or even rejects, with an error, such constructs.
When to specify the standard? Whenever you use the compiler. It is never a good idea to let the compiler just use whatever it wants.
If someone tries to use a compiler that is too old, then they will get a warning or error, and they will understand why the compile fails.
If a code contributor (maybe even yourself!) tries to add code using features that are too new, their code will be rejected. That's very important if you intend to keep compatibility with an older standard.
By explicitly stating the standard, using new features or extensions are a choice and don't happen by accident.
How to make a compilation successful for a program with a variable length array?(currently, Showing error : Variable sized array). I am using gcc in linux. How to make compiler compatible to c99 standard ? PLease help me in this. THanks in advance.
How to make compiler compatible to c99 standard?
By default, the compiler defaults to the most compatible version of C version is installed. Do define the compilation version explicitly, compile the program with the following command-line:
$ gcc -std=c99 -o my_program my_program.c
By defining the -std=c99, the compiler will be using C99 standard.
Edit: If you're still getting the warning and not the error, then you need to provide your code to know what exactly is wrong.
"How to make a compilation successful for a program with a variable length array? (currently, Showing error : Variable sized array)."
Usually it isn't an error to compile a code with a VLA unless you compile with -Werror flag.
The diagnostic you get is high-probably "only" a warning that you use a VLA inside of it, which is risky.
Thus, the compiler informs you about that.
So, you indeed can compile a program with VLAs without any error.
If you got errors they must belong to anything else. We can't find those out since you showed no specific code.
Take a look at this question of mine, not so long ago (even if it is for Clang, it covers the same topic as the answers suggest that a compiler is free to complain about whatever it likes):
Why does clang complain about using variable-length arrays with '-std=c99' flag?
All useful information you can find there.
VLAs are not portable. Try to use alternatives, for example dynamically allocated arrays by using malloc().
Related:
malloced array VS. variable-length-array
Is there any overhead for using variable-length arrays?
Is it a good idea to use C99 VLA compared to malloc/free?
"How to make compiler compatible to (the) C99 standard?"
As Rohan in his answer already said, you can use the -std-c99 flag at the invocation of gcc for that. But it probably won't solve your problem to do so.
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).
I am using this built-in atomic methods link
It is mentioned that:
The following built-in functions approximately match the requirements
for the C++11 memory model.
However I have tried compiling these methods with std=C99 and std=C89. The program compiles and I get the right results. Is there something I am missing here ?
Does C99 and C89 have a memory model as well ?
It is a compiler extension and therefore it is allowed to provide functionality outside of the what the standard allows but that page does not make it obvious that is the can be used in C.
Fortunately, gcc does have good online documents and if we check out for example the 4.9 series document on C extensions the __atomic Builtins points to the same page.
So that would indicate that it is valid to use in C and it will stick the requirements as laid out in the documentation and so it will work in the C99 as it does in C++. Usually if there is a difference between how a feature/extension is implemented between C and C++ the documents will note this, for example compound literals have significant differences.
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)