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.
Related
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.
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.
I want to get rid of all implicit-function-declaration warnings in my codebase. But there is a problem because some functions are
programmed into the microcontroller ROM at the factory and during linking a linker script provides only the function address. These functions are called by code in the SDK.
During compilation gcc of course emits the warning implicit-function-declaration. How can I get rid of this warning?
To be clear I understand why the warning is there and what does it mean. But in this particular case the developers of SDK guarantee that the code will work with implicit rules (i.e. implicit function takes only ints and returns an int). So this warning is a false positive.
This is gnu-C-99 only, no c++.
Ideas:
Guess the argument types, write a prototype in a header and include that?
Tell gcc to treat such functions as false positive with some gcc attribute?
You can either create a prototype function in a header, or suppress the warnings with the following:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wimplicit-function-declaration"
/* line where GCC complains about implicit function declaration */
#pragma GCC diagnostic pop
Write a small program that generates a header file romfunctions.h from the linker script, with a line like this
int rom_function();
for each symbol defined by the ROM. Run this program from your Makefiles. Change all of the files that use these functions to include romfunctions.h. This way, if the linker script changes, you don't have to update the header file by hand.
Because most of my programming expertise was acquired by self-study, I intentionally have become somewhat anal about resolving non-fatal warnings, specifically to avoid picking up bad coding habits. But, this has revealed to me that such bad coding habits are quite common, even from formally trained programmers. In particular, for someone like me who is also anal about NOT using MS Windows, my self-study of so-called platform-independent code such as OpenGL and Vulkan has revealed a WORLD of bad coding habits, particularly as I examine code written assuming the student was using Visual Studio and a Windows C/C++ compiler.
Recently, I encountered NUMEROUS non-fatal warnings as I designed an Ubuntu Qt Console implementation of an online example of how to use SPIR-V shaders with OpenGL. I finally threw in the towel and added the following lines to my qmake .PRO file to get rid of the non-fatal-warnings (after, first, studying each one and convincing myself it could be safely ignored) :
QMAKE_CFLAGS += -Wno-implicit-function-declaration
-Wno-address-of-packed-member
[Completely written due to commends]
You are compiling the vendor SDK with your own code. This is not typically what you want to do.
What you do is you build their SDK files with gcc -c -Wno-implicit-function-declaration and and your own files with gcc -c or possibly gcc -o output all-your-c-files all-their-o-files.
C does not require that declarations be prototypes, so you can get rid of the problem (which should be a hard error, not a warning, since implicit declarations are not valid C) by using a non-prototype declaration, which requires only knowing the return type. For example:
int foo();
Since "implicit declarations" were historically treated as returning int, you can simply use int for all of them.
If you are using C program, use
#include <stdio.h>
I couldn't disable it even though by using -std=c89 flag. How can I disable it?
You can generate an error for variable length arrays using a compiler flag:
-Werror=vla
Variable-length arrays in C89?
GCC always supported variable length arrays AFAIK. Setting -std to C89
doesn't turn off GCC extensions ...
See also:
https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
http://tigcc.ticalc.org/doc/gnuexts.html#SEC76
Finally,
http://tigcc.ticalc.org/doc/gnuexts.html
'-pedantic' and other options cause warnings for many GNU C
extensions. You can prevent such warnings within one expression by
writing __extension__ before the expression. __extension__ has no
effect aside from this.
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)