Here is the content of source file get.c :
#include <stdio.h>
int main(){
//int i = 0;
char b[10];
gets(b);
puts(b);
return 0;
}
When I compile it with these command
gcc -o get get.c -Wall -Werror
The output is
/tmp/ccYEWZvx.o: In function `main':
get.c:(.text+0x10): warning: the `gets' function is dangerous and should not be used.
But when change the code to
#include <stdio.h>
int main(){
int i = 0; // **this line just be uncommented**
char b[10];
gets(b);
puts(b);
return 0;
}
Using the same command, the output is
cc1: warnings being treated as errors
get.c: In function 'main':
get.c:4: error: unused variable 'i'
So, why this unused variable warning be treated as error, while the use of gets() not?
The gets() warning is being issued by the linker not the compiler, so the compiler settings do not apply.
Only the linker is able to determine that the symbol is resolved with the standard library gets() rather than some other implementation with the same name.
To instruct the linker to treat warnings as errors you need to pass it the --fatal-warnings option. In turn when not invoking the linker directly, options are passed to the linker by gcc using the -Wl option in a comma separated list:
gcc -o get get.c -Wall -Werror -Wl,--fatal-warnings
Note that the GNU linker is documented separately from the compiler, as part of binutils. The linker options are described here.
If you look at the output from the first example, it says the "error" is in an object file, which means it is generated by the linker.
The second error is generated by the compiler, which means there is no object file being generated and so the linker will not be invoked.
-Werror make all warnings as errors, to print only security warnings you can use: -Wformat -Wformat-security
You can read warnings options here https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
The compiler abort the compilation if an error is occurred, instead it continue the compilation if there are one or more warnings.
Related
I'm compiling with a command:
gcc grep.c -std=c99 -g -Winit-self -pedantic -w -o main2 && ./main2 lib text.txt
and I wish to receive warnings for initialized but not used variables and functions.
If you use -Wunused-variable it will warn for unused variables. But I recommend using -Wall -Wextra. Then you will get that for free with a bunch of other stuff.
When it comes to unused functions I refer to this: GCC -Wunused-function not working (but other warnings are working)
You can use the -Wunused-but-set-variable option to warn for these.
test.c:
int main(void)
{
int c = 0;
c = 3;
}
Example:
$ gcc test.c -Wunused-but-set-variable -o test
test.c: In function ‘main’:
test.c:3:9: warning: variable ‘c’ set but not used [-Wunused-but-set-variable]
int c = 0;
^
I have a large codebase of C code which part of it is generated code from the Oracle Pro*C precompiler.
We use the GNU gcc compiler.
The Pro*C precompiler generates code that contains unused variables that emits many warnings related to -Wunused-variable which I'd like to ignore.
I've tried the following which I found in other questions but it doesn't see to work for C code (cut down to a minimal example).
int main(void)
{
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
int a=0;
#pragma GCC diagnostic pop
int b=0;
return 0;
}
I still get the -Wunused-variable error for variable a.
aa.c: In function 'main':
aa.c:8:13: warning: unused variable 'b' [-Wunused-variable]
int b=0;
^
aa.c:6:14: warning: unused variable 'a' [-Wunused-variable]
int a=0;
^
GCC command:
gcc-8 -Wall -Wextra -pedantic aa.c -o a
Incase you are wondering, if I remove the pop pragma, no warnings are issued.
The solution I found was to add __attribute__((unused)) before the generated variables that were problematic. In this situation there are always only 4 relevant variables so it was possible.
I wrote a bash command in the make file right after the Pro*C precompiler:
for var in varA varB varC varD; do sed -i "0,/${var}/{s/\(${var}\)/__attribute__((unused))\1/}" $file_name; done
Hope it can be helpful for someone.
I created a basic C project in Xcode and modified the starter code in main.c slightly. I also went into the build settings and told it to use ANSI-C. Here's the code I have:
int main(int argc, const char * argv[])
{
// a statement!
printf("Hello, World!\n");
// shouldn't this cause a compiler error?
// the variable isn't declared at the top of the scope.
int x;
x += 10;
return 0;
}
Obviously, it doesn't do much, but I expected the variable declaration to produce a compiler error (since older versions of C require variable declarations at the beginning of the scope, before other statements). However, Xcode happily compiles it and runs it with neither an error or warning.
I might be making a dumb mistake somewhere, but I'm trying to understand why this code compiles. I've read that C99 and C11 allow you to declare variables anywhere, so this would work, but I explicitly set the project to use ANSI-C. Is this just the way Apple's LLVM compiler works? Or am I missing something elsewhere?
TL;DR You need to add -pedantic (or -Wdeclaration-after-statement) to -ansi to get the warning you want.
Somewhat to my surprise, both clang (from Apple XCode 7.2) and gcc (from GCC 5.3.0, which I built), accept the code when compiled with either -std=c90 or -ansi even though it is not strictly compliant with C90.
However, both complain when told to be -pedantic.
$ clang -ansi -c xyz.c
$ clang -std=c90 -c xyz.c
$ gcc -std=c90 -c xyz.c
$ which gcc
/opt/gcc/v5.3.0/bin/gcc
$ gcc -std=c90 -pedantic -c xyz.c
xyz.c: In function ‘main’:
xyz.c:7:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
int x;
^
$ clang -pedantic -std=c90 -c xyz.c
xyz.c:7:9: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement]
int x;
^
1 warning generated.
$ clang -pedantic -ansi -c xyz.c
xyz.c:7:9: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement]
int x;
^
1 warning generated.
$
The file xyz.c is your source code with the comments stripped, #include <stdio.h> added at the top, and int main(void) in place of int main(int argc, char **argv) since the code doesn't use the arguments.
Note that your code has undefined behaviour; incrementing an uninitialized variable is a bad idea.
I have the next code :
test.c
#include "a1.h"
int main() {
int a = 8;
foo(a);
return a;
}
a1.h
void foo (int a);
a1.c
int f = 0;
void foo (int a, int b){
f=5+a+b;
return;
}
Pay attention that in a1.c foo has 1 more parameter than the prototype defined in a1.h.
The compiler isn't issue a warning or an error and so as coverity :
make all
Building file: ../src/a1.c
Invoking: GCC C Compiler
gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/a1.d" -MT"src/a1.d" -o "src/a1.o" "../src/a1.c"
Finished building: ../src/a1.c
Building file: ../src/test.c
Invoking: GCC C++ Compiler
gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/test.d" -MT"src/test.d" -o "src/test.o" "../src/test.c"
Finished building: ../src/test.c
Building target: test
Invoking: GCC C++ Linker
gcc -o "test" ./src/a1.o ./src/test.o
Finished building target: test
How can I defend myself in those cases ? I know that if I will add #include "a1.h" in the a1.c file I will get an error but is there a way to get an error without the "include " ?
Compiler isn't issuing a warning because it does not know that foo(int) from a1.h header and foo(int,int) from a1.c file is the same function. C++ allows functions to be overloaded, so both functions could potentially coexist. That is why C++ compiler cannot detect this problem, so you need to wait until the linking stage.
If you were compiling using C, not C++, you could have the compiler detect this condition simply by including a1.h at the top of a1.c file.
You're overloading foo. The version with only one parameter is never defined, hence you should get a linker error when using it.
How can I defend myself in those cases ?
You can't defend yourself from function overloading. Just make sure that you've got the same signature in both the header as the source file.
Every time I compile I get the following error message:
Undefined reference to ( function name )
Let's say I have three files: Main.c, printhello.h, printhello.c. Main.c calls function print_hello(), which returns "Hello World". The function is defined in printhello.c.
Now, here's the following code of printhello.h:
#ifndef PRINTHELLO_H
#define PRINTHELLO_H
void print_hello();
#endif
I am sure this code is fine. I still don't know why is it giving me the error, though. Can you help me?
Undefined references are the linker errors. Are you compiling and linking all the source files ? Since the main.c calls print_hello(), linker should see the definition of it.
gcc Main.c printhello.c -o a.out
The error is, I think, a linker error rather than a compiler error; it is trying to tell you that you've not provided all the functions that are needed to make a complete program.
You need to compile the program like this:
gcc -o printhello Main.c printhello.c
This assumes that your file Main.c is something like:
#include "printhello.h"
int main(void)
{
print_hello();
return 0;
}
and that your file printhello.c is something like:
#include "printhello.h"
#include <stdio.h>
void print_hello(void)
{
puts("Hello World");
}
Your declaration in printhello.h should be:
void print_hello(void);
This explicitly says that the function takes no parameters. The declaration with the empty brackets means "there is a function print_hello() which returns no value and takes an indeterminate (but not variadic) list of arguments", which is quite different. In particular, you could call print_hello() with any number of arguments and the compiler could not reject the program.
Note that C++ treats the empty argument list the same as void print_hello(void); (so it would ensure that calls to print_hello() include no arguments), but C++ is not the same as C.
Another way to do it is to explicitly build object files for the printhello:
gcc -c printhello.c -o printhello.o
gcc -o Main main.c printhello.o
This has the added benefit of allowing other programs to use the print_hello method
It seems that the error is from the linker and not the compiler. You need to compile and link both the source files. I think what you are doing is simply including the header file in Main.c and you are not compiling the printhello.c
You need to :
gcc Main.c printhello.c -o myprog
or
construct the object files first
gcc -c printhello.c
gcc -c Main.c
then link them
gcc Main.o printhello.o