Surprisingly I found gcc can find this error when it compiles C. I simplified the code which still triggers the warning. I post the question for making clear the details of the techniques it uses. Below is my code of file a.c
int main(){
int a[1]={0};
return(a[1]);
}
My gcc version is gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3. When using gcc a.c -Wall, there is no warning; when using gcc -O1 a.c -Wall, there is a warning:
warning: ‘a[1]’ is used uninitialized in this function [-Wuninitialized]
and when using gcc -O2 a.c -Wall (or -O3), there is another warning:
warning: array subscript is above array bounds [-Warray-bounds]
The most surprising thing is that, when I give a[1] a value, then none of the above compiling options gives any warning. There is no warning even when I change the index to a huge number (of course the compiled file offends the operating system and will be kicked out),
int main(){
int a[1]={0};
a[2147483648]=0;
return(a[2147483648]);
}
I think the above phenomenon is more of a function than a bug. I hope someone help me figure out what happens, and/or why the compiler is designed so. Many thanks!
Accessing memory past the end of the array results in undefined behaviour.
gcc is nice enough to go out of its way to detect, and warn you about, some of these errors. However, it is under no obligation to do so, and certainly cannot be expected to catch all such errors.
The compiler is not required to provide diagnostic for this kind of error, but gcc is often able to help; notice that these warnings often arise in part as a byproduct of the static analysis passes done for optimization purposes, which means that, as you noticed, such warnings often depend from the specified optimization level.
Related
In a quite large code base, I found the following construct (rewritten snippet) in a cpp file
int main()
{
bool b;
//... some code ...;
b = "False"
}
This is completely legal code, but clearly not intentional. It is easily fixed, but it has been present since 2014 without anyone noticing, so it is obviously not easy to spot.
Is it possible to make gcc warn about this?
Neither g++ 7 nor clang++ 5 warn with -Wall -Wextra -Wpedantic.
Clang has a warning called -Wstring-conversion that will catch the mistake, but gcc doesn't have it. I briefly looked through the gcc warning documentation page and didn't find anything that would catch the mistake.
live wandbox example
I've filed a report for a feature suggestion on the gcc bug tracker: #80151.
I'm using Clang v3.7.0 with Mingw-w64 5.1.0 and GCC 5.1.0, all 64-bit, on Windows 10. My goal is to use a set of Clang and GCC options that will give me the best chance of detecting potential C89 and C++98 language standards portability issues across many different compilers. For example, for C I have been using the following GCC command line with pretty good success:
gcc -c -x c -std=c89 -pedantic-errors -Wall -Wextra -Wno-comment -Wno-parentheses -Wno-format-zero-length test.c
However, I recently tried it with Clang and got a different result. Here is my sample test code:
int main(void)
{
int length = (int)strlen("Hello");
return 0;
}
With Clang I get the following error, whereas with GCC I get the same basic thing, but it flags it as a warning instead:
test.c:3:22: error: implicitly declaring library function 'strlen'
with type 'unsigned long long (const char *)'
int length = (int)strlen("Hello");
If I remove the -pedantic-errors option, or just change it to -pedantic, Clang then only flags it as a warning, which is what I actually want. However, according to the GCC documentation the -pedantic-errors option causes warnings that are considered language extensions to be flagged as errors, but not using a prototype for a function is not an extension in C89. So, I have three basic questions:
Has Clang changed the meaning of -pedantic-errors from the meaning used by GCC, or am I misinterpreting something?
What is the best set of options that will enforce adherence to the selected standard and will issue errors for all non-conforming code?
If I continue to use -pedantic-errors with Clang is there a way to get it to issue a warning instead of an error in specific cases? In another posting on this site an answer was given that said to use the following, where foo is the error:
-Wno-error=foo
If that is a correct approach, what do I actually use in place of foo for an error like I'm getting since there is no actual error number indicated? I can't believe it actually wants all of the following:
-Wno-error=implicitly declaring library function 'strlen'
with type 'unsigned long long (const char *)'
Your code is invalid, and the behavior is undefined, so the compiler can do anything also when compiling. The implicitly declared int strlen(char*) is not compatible with size_t strlen(const char *).
Has Clang changed the meaning of -pedantic-errors from the meaning used by GCC, or am I misinterpreting something?
As I read it, yes. From clang documentation:
-pedantic-errors
Error on language extensions.
In GCC:
-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++ [...]
-pedantic-errors
Give an error whenever the base standard (see -Wpedantic) requires a diagnostic, in some cases where there is undefined behavior at compile-time and in some other cases that do not prevent compilation of programs that are valid according to the standard.
Clang errors on extensions.
GCC errors when standard explicitly requires it and in other "some cases".
This is a different, it is a different set of errors. Standard may not require a diagnostic, but it's still an extension - GCC will be silent, Clang will error.
What is the best set of options that will enforce adherence to the selected standard and will issue errors for all non-conforming code?
The first answer that comes to mind is: "none". Compiler inherently use "implementation-defined behavior" and extension, because they are meant to compile the code in the first place, not meant to not compile non-conforming code. There are cases where the code is conforming, but still the behavior differs between compilers - you can explore such a case here.
Anyway, keep using -pedantic-errors, as it seems to work in detection of non-conforming code. Your code is invalid, the behavior is undefined, so your code is non-conforming, so clang properly detects it. Also use linters and sanitizers to detect other cases of undefined behavior.
If I continue to use -pedantic-errors with Clang is there a way to get it to issue a warning instead of an error in specific cases?
Use -fno-builtin.
Here is my code:
#include <string>
struct A
{
int a;
std::string sa;
};
int main()
{
A arr[3]{};
}
When I compile it with gcc 4.8.2 (on Ubuntu 14.04) with -std=gnu++11 option I get the following error:
example.cpp: In function ‘int main()’:
example.cpp:11:14: internal compiler error: in gimplify_init_constructor, at gimplify.c:4271
A arr[3]{};
^
Why does it throw an internal compiler error? Is it a compiler bug?
An internal compiler error is always a compiler bug, and says nothing about whether the code is valid.
If the code is invalid, the compiler is supposed to give an error message telling you what's wrong with the code. An internal compiler error only tells you what's wrong with the compiler.
Given that this internal compiler error still exists in later versions (I just checked 4.9.2, as well as current sources as of January 29th), I would normally strongly encourage reporting this as a bug to the GCC developers, but a quick search reveals that it's already known to them.
You can work around it by writing A arr[3]{{}};, which means the same thing. It contains the same initialiser for the first element of arr that it would already get by default.
I encountered the same issue right out of blue with gcc 4.8.5 when I added an std::string to a content of the array struct. Adding extra {} as suggested above helped. Maybe this can give a clue why this compiler error happens.
Is it possible to 'tell' compiler that if total number of warnings (while compiling a C++ program) are more than say 10 then stop compiling further, and emit an error?
Or is it possible to hack a compiler like clang to provide this functionality.
GCC has two options together would achieve this, from gnu online docs:
-Werror
Make all warnings into errors.
-fmax-errors=n
Limits the maximum number of error messages to n, at which point GCC bails out rather than attempting to continue processing the source
code.
This would make a build with any warnings fail though, the options just define when to stop parsing.
I haven't seen this kind of feature in gcc or clang. You can certainly try to patch it into either of them, both are open source. There is also -Werror (accepted by both compilers) which simply treats warnings as errors.
How about using -Werror to make warnings into errors and -fmax-errors=n to set the limit.
(Also, perhaps making your code completely warning free would be a good thing).
I wrote a program for an assignment in which I allocated memory in this way:
EdgeBucket* edgeTable[ n_scanlines ];. I understand that this is normally illegal in C, but I was not aware that it could also not be done in C++. However, when I compile it using g++, it gives no compile errors. But my grader is using a visual studio, and when he attempted to build my program, it gave errors stating that the length of the array must be constant. I normally compile my programs with the -ansi and -Wall options to ensure cross compiler integrity, but even that didn't detect this. I am concerned about my grades being compromised by this, so does anyone know why the -ansi compiler didn't catch this, and what can be done to prevent further cross compiler discrepancies?
Use -pedantic-errors flag. Example.
They are known as VLAs (Variable Length Arrays). The are legal in C from C99 and illegal in C++.