my code shows this warnings when compiling with "g++ -Wall -pedantic -Wno-long-long -c main.c". I have to compile in this mode, becouse its a homework and we have an application that corrects them and it uses this compile mode.
Error: invalid conversion from "void" to "int** " [-fpermissive]
Error: invalid conversion from "void" to "int* " [-fpermissive]
Error: invalid conversion from "void" to "main(int, char*)::VYSLEDEK" [-fpermissive]
the same errors continue as i realloc quite a lot in my program. I tried to change almost everything in that realloc, it is still the same.
Parts of the code :
struct VYSLEDEK
{
int sirka;
int vyska;
int zacatek_x;
int zacatek_y;
int soucet;
} *vysledek;
int **matice,**soucty;
.....
matice=(int**)malloc(1*sizeof(int*));
matice[0]=(int*)malloc(1*sizeof(int));
soucty=(int**)malloc(1*sizeof(int*));
soucty[0]=(int*)malloc(1*sizeof(int));
.....
1. matice=realloc(matice,naalokovano*2*sizeof(int*));
2. soucty=realloc(soucty,naalokovano*2*sizeof(int*));
.....
for (i=0;i<(naalokovano*2);i++)
{
3. matice[i]=realloc(matice[i],sizeof(int));
4. soucty[i]=realloc(soucty[i],sizeof(int*));
};
.....
5. vysledek=realloc(vysledek,vysledku*sizeof(struct VYSLEDEK*));
Thank you for your help.
You already did cast the result of malloc to the right type. Do the same for the realloc calls, too.
BTW: Don’t complain that they force you to switch on the warnings. I think it’s the most sensible thing to do by default, I always use at least -Wall -Werror.
Related
https://github.com/noyesno/awka
For the above repo, I got the following error when I try to compile it on macOS (gcc is just clang). I have no idea how to fix the problem according to the error message. It compiles fine on Linux.
I also tried the real gcc from Homebrew to compile the package. It also show the same error. How can I fix this problem on macOS?
$ ./configure
$ make
...
gcc -O -Dawka_LIBDIR=\"/usr/local/lib\" -Dawka_INCDIR=\"/usr/local/include\" -c -o print.o print.c
print.c:52:11: error: expected parameter declarator
int PROTO(sprintf, (char *, const char *,...)) ;
^
print.c:52:11: error: expected ')'
print.c:52:11: note: to match this '('
print.c:52:11: error: conflicting types for '__builtin___sprintf_chk'
int PROTO(sprintf, (char *, const char *,...)) ;
^
print.c:52:11: note: '__builtin___sprintf_chk' is a builtin with type 'int (char *, int, unsigned long, const char *, ...)'
3 errors generated.
make[1]: *** [<builtin>: print.o] Error 1
make[1]: Leaving directory '/private/tmp/awka/awka'
make: *** [Makefile:48: awka_exe] Error 2
I'm not going to spend ages on this, but it looks as though configure is gripping stdio.h looking for sprintf. It is unable to find it in the header, and so it adds the #define:
NO_SPRINTF_IN_STDIO
which it sets to 1, and uses it to add its own prototype for sprintf. Unfortunately, this appears to be a macro in this case, which replaces sprintf with '__builtin___sprintf_chk' instead (which has additional string length checks by the looks of it).
Possible solutions:
Comment out the line in print.c, and make sure stdio.h is included somewhere.
After running configure, search for where it defines NO_SPRINTF_IN_STDIO and set that var to 1?
Fix the configure to so a more rigorous test?
The following simple C example program correctly emits a compile warning:
#include <stdio.h>
int main(int argc, char *argv[])
{
int *p = NULL;
int q = 1;
if(1 == 2 ? p : q) { printf("Info\n"); }
return(0);
}
The warning emitted is "warning: pointer/integer type mismatch in conditional expression".
In clang, the parameter "-Wno-conditional-type-mismatch" works in such a way that no warnings appear for the example code.
In GCC, I was looking for a similar option. The best I could find was the parameter "-fcond-mismatch", which would allow the example code. From the man page:
Allow conditional expressions with mismatched types in the second and third arguments. The
value of such an expression is void. This option is not supported for C++.
But when using this option, GCC keeps complaining:
# gcc -fcond-mismatch -c example.c
example.c: In function 'main':
example.c:8:17: warning: pointer/integer type mismatch in conditional expression
8 | if(1 == 2 ? p : q) { printf("Info\n"); }
Using GCC 10.3.0, would there be a GCC option or compiler flag to suppress the warning, in a similar way as clang does?
I don't think there is any such flag. GCC's manual says, under -Werror=, "The warning message for each controllable warning includes the option that controls the warning."
Since this message does not mention such an option, this suggests it is not controllable.
gcc version - gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
Compiling below code with -Wall -Wuninitialized is throwing warning as expected
warning: ‘test’ is used uninitialized in this function [-Wuninitialized]
#include<stdio.h>
#include<stdlib.h>
void check (int test )
{
printf("%d",test);
}
int
main()
{
int test;
check(test);
return 0;
}
But compiling below code with -Wall -Wuninitialized is not throwing warning
#include<stdio.h>
#include<stdlib.h>
void check (int test )
{
printf("%d",test);
}
int
main()
{
int test;
int condition = 0;
if(condition == 27)
test = 10;
check(test);
return 0;
}
Shouldn't it throw warning?. is it anyway related to compiler optimization?
What an user understands as a false positive may be different for the particular
user. Some users are interested in cases that are hidden because of
actions of the optimizers combined with the current environment.
However, many users aren't, since that case is hidden because it
cannot arise in the compiled code. The canonical example is (MM05):
int x;
if (f ())
x = 3;
return x;
where 'f' always return non-zero for the current environment, and
thus, it may be optimised away. Here, a group of users would like to
get an uninitialized warning since 'f' may return zero when compiled
elsewhere. Yet, other group of users would consider spurious a warning
about a situation that cannot arise in the executable being compiled.
https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#Proposal
EDIT: MMO5 is already fixed
https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#MM05
Yes, gcc is not warning you because the code is optimized away. Some people think this is the right thing, because it might be that way by a compile time configuration value. Others think it's the wrong thing, because it hides possible mistakes.
You are not the first to notice this problem with GCC. There's a whole proposal about it.
clang with -Wall detects the problem and even suggests a fix.
$ make
cc -Wall -g test.c -o test
test.c:15:7: warning: variable 'test' is used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
if(condition == 27)
^~~~~~~~~~~~~~~
test.c:18:10: note: uninitialized use occurs here
check(test);
^~~~
test.c:15:4: note: remove the 'if' if its condition is always true
if(condition == 27)
^~~~~~~~~~~~~~~~~~~
test.c:12:12: note: initialize the variable 'test' to silence this warning
int test;
^
= 0
1 warning generated.
I know you quickly clicked this expecting to answer NEVER USE GETS! but I have a valid reason. I am learning about buffer overflows and need to purposely develop vulnerable software.
So, as the title states, how do I ignore the warnings so the compilation succeeds? I have tried:
gcc bo.c -o bo -Wall
... to no avail.
Thanks for any help.
This code:
#include <stdio.h>
int main() {
char foo[10];
gets( foo );
return 0;
}
produces the following output when compiled:
bo.c: In function 'main':
bo.c:4:2: warning: 'gets' is deprecated (declared at /usr/include/stdio.h:638) [-Wdeprecated-declarations]
gets( foo );
^
/tmp/cclk8TkP.o: In function `main':
bo.c:(.text+0x10): warning: the `gets' function is dangerous and should not be used.
The first warning is from the compiler, and we can see what flag to use to suppress it: -Wno-deprecated-declarations.
This leaves the second warning, which is from the linker. As far as I can tell there is no way to suppress that warning easily (see here and here). However it should not be a problem, since it is a warning, not an error; the executable gets created.
use fgets instead of gets
Example:
fgets (foo, sizeof(foo), stdin);
We want to start using -Wall -Werror on a large project.
Due to the size, this change has to be phased, and we want to start with the most important warnings first.
The best way to do it seems to be using -Wall -Werror, with exceptions for specific warnings. The exceptional warnings are those which we have a lot of (so fixing them all is hard and risky), and we don't consider them very dangerous.
I'm not saying we don't want to fix all these warnings - just not on the first phase.
I know two ways to exclude a warning from -Werror - the best is -Wno-error=xxx, and if it doesn't work - -Wno-xxx (of course, we prefer to see the warning and ignore it, rather than hide it).
My problem is with warnings which are enabled by default, and don't have a -Wxxx flag related to them. I couldn't find any way to alllow them when -Werror is used.
I'm specifically concerned about two specific warnings. Here's a program that exhibits them and the compiler output:
#include <stdio.h>
void f(int *p) { printf("%p\n", p); }
int main(int argc, char *argv[]) {
const int *p = NULL;
const unsigned int *q = NULL;
f(p); /* Line 7: p is const, f expects non const */
if (p == q) { /* Line 8: p is signed, q is unsigned */
printf("Both NULL\n");
}
return 0;
}
% gcc warn.c
warn.c: In function 'main':
warn.c:7: warning: passing argument 1 of 'f' discards qualifiers from pointer target type
warn.c:8: warning: comparison of distinct pointer types lacks a cast
I know the best solution is to fix these warnings, but it's much easier said than done. In order for this change to be successful, we have to do this phased, and can't do too many changes at once.
Any suggestions?
Thanks.
What about phasing on a compilation unit/module/library basis instead of per warning? Is triggering a subtarget compilation an option (a good-enough build system in place)?
It might be folly, but ...
Why not a simple grep ?
something like
gcc teste.c 2>&1 | grep -v 'comparison of distinct' | grep -v 'some_other_string'
You probably want to hide these greps in a script, and call the script from your makefile instead of gcc
According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43245 it will be "-Wdiscarded-qualifiers", but since the bug-fixed entry is from May 1, 2014, the gcc compiler you are using might not support it.