For the following program, I do not get a warning that uoff.Reg and s.i is used without initialization. gcc (with -Wextra) and clang (with -Weverything) both do not warn, as I expected.
#include<stdint.h>
typedef union {
uint32_t Reg;
struct {
uint16_t Cx;
uint16_t sf;
};
} tf;
typedef struct {
uint16_t i;
uint16_t j;
} st;
int bar(tf, tf);
int foo(tf t0, int32_t offset) {
tf uoff;
st s;
t0.Reg = uoff.Reg + s.i + (uint32_t)offset;
t0.sf = uoff.sf;
return bar(t0, uoff);
}
I'm wondering why I'm not getting any warning. Does standard (C/C++) say that aggregates with automatic storage are initialized (by default) to zero, or is it a compiler limitation?
I checked gcc, : http://coliru.stacked-crooked.com/a/f1b25f7f369fbdbc, and warnings does get generated
here is how it gets compiled:
g++-4.8 -std=c++11 -O2 -Wall -pedantic -pthread main.cpp && ./a.out
and output:
main.cpp:10:3: warning: ISO C++ prohibits anonymous structs [-Wpedantic]
};
^
main.cpp: In function 'int foo(tf, int32_t)':
main.cpp:23:21: warning: 'uoff.tf::Reg' is used uninitialized in this function -Wuninitialized]
t0.Reg = uoff.Reg + s.i + (uint32_t)offset;
^
main.cpp:23:21: warning: 's.st::i' is used uninitialized in this function -Wuninitialized]
/tmp/ccIy8fGt.o: In function `foo(tf, int)':
main.cpp:(.text+0xa): undefined reference to `bar(tf, tf)'
collect2: error: ld returned 1 exit status
In order to guarantee zero-initialization of POD aggregate data members, you need to value-initialize your instance. For example,
st s = st(); // C++03 and C++11
st s = {}; // C++03 and C++11
st s{}; // C++11
Compilers are not required to warn you about uninitializad variables. However, the minimal set of compilation flags needed to get a warning with g++ seem to be
-Wuninitialized -O2
In other words, it seems that without optimization, the warning disappears. It could be that in this case variables get zero initialized.
Does standard (C/C++) say that aggregates with automatic storage are
initialized (by default) to zero
No, it doesn't. Automatic variables are not initialized, their value is initially left undefined. Using them without initialization results in undefined behavior.
However, naturally, the standard doesn't require you to initialize variables, compilers are free to warn about this, but using an uninitialized variable is not a constraint violation, thus, implementations do not have to warn you.
No, the C-Standard does not require the compiler to generate code to initialise auto variables. Reading their value without prior initialisation provokes undefined behaviuor.
However, this code
int main(void)
{
int a;
int b = a;
b = b;
return 0;
}
compiled using gcc's option -Wall, gives:
main.c:4: warning: ‘a’ is used uninitialized in this function
[gcc (Debian 4.4.5-8) 4.4.5]
Related
Consider the following code:
#include <tuple>
struct A {
template <typename... Types> operator std::tuple<Types...>() {
int i = 0;
return std::tuple<Types...>{Types(i++)...};
}
};
struct B {
B(int i){};
};
int main() {
A a;
std::tuple<B, B> t{a};
}
It produces the following warnings in gcc
$ g++-12 main.cpp -std=c++20 -Wall
main.cpp: In instantiation of ‘A::operator std::tuple<_UTypes ...>() [with Types = {B, B}]’:
main.cpp:18:23: required from here
main.cpp:7:46: warning: operation on ‘i’ may be undefined [-Wsequence-point]
7 | return std::tuple<Types...>{Types(i++)...};
| ^
main.cpp:7:46: warning: operation on ‘i’ may be undefined [-Wsequence-point]
but not in clang:
clang++-14 main.cpp -std=c++20 -Wall
main.cpp:18:20: warning: unused variable 't' [-Wunused-variable]
std::tuple<B, B> t{a};
^
1 warning generated.
Why?
This may be related but the referenced gcc bug is already fixed. I have gcc --version gcc (Debian 12.2.0-9) 12.2.0.
The order of evaluation of elements in a braced-init-list is strictly left-to-right, already since C++11, and regardless of the context in which the syntax is used. See https://timsong-cpp.github.io/cppwp/n3337/dcl.decl#dcl.init.list-4.
So the warning is bogus. #Artyer linked this bug report for a false positive warning under the question, which probably covers your example as well.
As mentioned in the other bug report you linked, GCC had actual wrong code generation for similar cases in earlier versions though, so you might want to be careful when relying on this order.
int main()
{
int a = 10;
int b;
a = b;
}
Valgrind can not warn me that b is uninitialized.
Your compiler should warn you regaring the uninitialized variable. If it doesn't, maybe the warnings are turned off?
This is gcc (9.3.0) output (with -Wall -Wextra option) :
prog.cc: In function 'int main()':
prog.cc:3:9: warning: variable 'a' set but not used [-Wunused-but-set-variable]
3 | int a = 10;
| ^
prog.cc:5:7: warning: 'b' is used uninitialized in this function [-Wuninitialized]
5 | a = b;
| ~~^~~
and this clang (10.0.0):
prog.cc:5:9: warning: variable 'b' is uninitialized when used here [-Wuninitialized]
a = b;
^
prog.cc:4:10: note: initialize the variable 'b' to silence this warning
int b;
^
Compile it with -Wall flag
gcc a.c -Wall -o a
Valgrind will only output errors if there is some potential impact on the behaviour of your application. In this case it does not matter that b is uninitialized.
Valgrind is, however, tracking the state of the memory.
If you run
valgrind --vgdb-error=0 ./test_exe
Then open another terminal and follow the instructions that were printed by Valgrind in the 1st terminal, then you can run commands like
mo xb {addess of b} 4
See here for details.
Within the language, there is no way to check for indeterminate values.
In simple cases such as this, compilers can detect it and you can ask to be warned about them. See the manual of your compiler for available warning options.
Compilers also provide "sanitisers" which check for bugs at runtime and are not limited by the complexity of the program as much as the compiletime warnings are. For reads of indeterminate values, a memory sanitiser would be the choice. They don't catch everything though, and the ones I tested did not catch the bug in your program. They could detect it if the indeterminate value was used to control the flow of the program:
int a = 10;
int b;
if (b) // detected by memory sanitiser
b = a;
Visual Studio Community (free) warns:
error C4700: uninitialized local variable 'b' used
It seems that clang is ignoring warnings which occur in included header files:
// what.hpp
class What {
public:
What() {
int x = x;
}
};
// main.cpp
#include <iostream>
#include "what.hpp"
int main()
{
int y = y;
std::cout << "y is: " << y << std::endl;
What w;
}
Compiling this with g++ (4.9.2) gives:
$ g++ -dumpversion && g++ -Wall -Wextra main.cpp -o main
4.9.2
In file included from main.cpp:3:0:
what.hpp: In constructor ‘What::What()’:
what.hpp:5:17: warning: ‘x’ is used uninitialized in this function [-Wuninitialized]
int x = x;
^
main.cpp: In function ‘int main()’:
main.cpp:5:13: warning: ‘y’ is used uninitialized in this function [-Wuninitialized]
int y = y;
Compiling the same thing with clang:
$ clang++ --version && clang++ -Wall -Wextra main.cpp -o main
Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based on LLVM 3.6.0)
Target: x86_64-pc-linux-gnu
Thread model: posix
main.cpp:5:13: warning: variable 'y' is uninitialized when used within its own initialization [-Wuninitialized]
int y = y;
~ ^
1 warning generated.
I'm not sure, If I'm using clang wrong or if this is indeed a bug?
Any hints? Thanks in advance.
This is not clang bug, the warning is being suppressed because x is subsequently unused, the bug report I cite below explains the rationale behind this behavior.
In this specific case it is considered a clang feature to not to produce this warning(Wuninitialized) if the variable is otherwise unused, although most will probably find this surprising behavior.
We can see the rationale from the following bug report: No uninitialized warning for self-initialization (e.g., int x = x):
Right, this is deliberate, and is considered to be a feature rather
than a bug. We suppress the warning on 'int x = x;' only in the case
where 'x' is otherwise unused.
It is mentioned in the bug report that self-intialization in this way is:
considered the canonical way to suppress "use of uninitialized
variable" warnings
This does not depend on whether the code in question is included from a header, I put together a live example that shows the warning does not show up when the code is all in one file.
Note, initializing a variable in this way:
int x = x;
is undefined behavior, for reference see:
Does initialization entail lvalue-to-rvalue conversion? Is int x = x; UB?
Has C++ standard changed with respect to the use of indeterminate values and undefined behavior in C++14?
So in general we can not have any expectations as to the result and the compiler is not obligated to issue a diagnostic although doing so can be helpful.
The lines in question are syntactically correct. Neither are particularly useful lines of code - both exhibit undefined behavior - but they're legal C++ code. As such, the compiler is not obligated to issue any diagnostic.
This is just a quality of implementation issue - the compiler isn't obligated to issue warnings in this case, but it's very helpful when it does. As to why clang happens to warn only for y and not for x, whereas gcc warns for both - I am not sure. It definitely has nothing to do with included header files (you can see for yourself by just defining What in main.cpp) and likely has to do with the fact that you're printing y and never reading from x again.
But you can't rely on complete accuracy with these warnings. When you get them, however, they're always worth paying attention to.
In C++, it is possible for pointer values to be compile-time constants. This is true, otherwise, non-type template parameters and constexpr won't work with pointers. However, as far as I know, addresses of functions and objects of static storage are known (at least) at link-time rather than compile-time. Following is an illustration:
main.cpp
#include <iostream>
template <int* p>
void f() { std::cout << p << '\n'; }
extern int a;
int main() {
f<&a>();
}
a.cpp
int a = 0;
I'm just wondering how the address of a could possibly be known when compiling main.cpp. I hope somebody could explain this a little to me.
In particular, consider this
template <int* p, int* pp>
constexpr std::size_t f() {
return (p + 1) == (pp + 7) ? 5 : 10;
}
int main() {
int arr[f<&a, &b>()] = {};
}
How should the storage for arr be allocated?
PLUS: This mechanism seems to be rather robust. Even when I enabled Randomized Base Address, the correct output is obtained.
The compiler doesn't need to know the value of &a at compile time any more than it needs the value of function addresses.
Think of it like this: the compiler will instantiate your function template with &a as a parameter and generate "object code" (in whatever format it uses to pass to the linker). The object code will look like (well it won't, but you get the idea):
func f__<funky_mangled_name_to_say_this_is_f_for_&a>__:
reg0 <- /* linker, pls put &std::cout here */
reg1 <- /* hey linker, stuff &a in there ok? */
call std::basic_stream::operator<<(int*) /* linker, fun addr please? */
[...]
If you instantiate f<b&>, assuming b is another global static, compiler does the same thing:
func f__<funky_mangled_name_to_say_this_is_f_for_&b>__:
reg0 <- /* linker, pls put &std::cout here */
reg1 <- /* hey linker, stuff &b in there ok? */
call std::basic_stream::operator<<(int*) /* linker, fun addr please? */
[...]
And when your code calls for calling either of those:
fun foo:
call f__<funky_mangled_name_to_say_this_is_f_for_&a>__
call f__<funky_mangled_name_to_say_this_is_f_for_&b>__
Which exact function to call is encoded in the mangled function name.
The generated code doesn't depend on the runtime value of &a or &b.
The compiler knows there will be such things at runtime (you told it so), that's all it needs. It'll let the linker fill in the blanks (or yell at you if you failed to deliver on your promise).
For your addition I'm afraid I'm not familiar enough about the constexpr rules, but the two compilers I have tell me that this function will be evaluated at runtime, which, according to them, makes the code non-conforming. (If they're wrong, then the answer above is, at least, incomplete.)
template <int* p, int* pp>
constexpr std::size_t f() {
return (p + 1) == (pp + 7) ? 5 : 10;
}
int main() {
int arr[f<&a, &b>()] = {};
}
clang 3.5 in C++14 standards conforming mode:
$ clang++ -std=c++14 -stdlib=libc++ t.cpp -pedantic
t.cpp:10:10: warning: variable length arrays are a C99 feature [-Wvla-extension]
int arr[f<&a, &b>()];
^
1 warning generated.
GCC g++ 5.1, same mode:
$ g++ -std=c++14 t.cpp -O3 -pedantic
t.cpp: In function 'int main()':
t.cpp:10:22: warning: ISO C++ forbids variable length array 'arr' [-Wvla]
int arr[f<&a, &b>()];
As far as I know, the variables of static storage and functions are stored simply as symbols/place holders in the symbol table while compiling. It is in the linking phase when the place holders are resolved.
The compiler outputs machine code keeping the placeholders intact. Then the linker replaces the placeholders of the variables / functions with their respective memory locations. So in this case too, if you just compile main.cpp without compiling a.cpp and linking with it, you are bound to face linker error, as you can see here http://codepad.org/QTdJCgle (I compiled main.cpp only)
I understand that VLAs are not part of C++11 and I have seen this slip by GCC. It is part of the reason I switched to Clang. But now I am seeing it Clang too. I am using clang 3.2 (one behind the latest) and I am compiling with
-pedantic and -std=c++11
I expect my test to NOT compile yet it compiles and runs.
int myArray[ func_returning_random_int_definitely_not_constexpr( ) ];
Is this a compiler bug or an I missing something?
In response to the comment here is the random_int_function()
#include <random>
int random_int_function(int i)
{
std::default_random_engine generator;
std::uniform_int_distribution<int> distribution(1,100);
int random_int = distribution(generator);
return i + random_int;
}
Yes, variable length arrays are supported in clang 3.2/3.3 contrary to
the C++11 Standard (§ 8.3.4/1).
So as you say, a program such as:
#include <random>
int random_int_function(int i)
{
std::default_random_engine generator;
std::uniform_int_distribution<int> distribution(1,100);
int random_int = distribution(generator);
return i + random_int;
}
int main() {
int myArray[ random_int_function( 0 ) ];
(void)myArray;
return 0;
}
compiles and runs. However, with the options -pedantic; -std=c++11 that
you say you passed, clang 3.2/3,3 diagnoses:
warning: variable length arrays are a C99 feature [-Wvla]
The behaviour matches that of gcc (4.7.2/4.8.1), which warns more emphatically:
warning: ISO C++ forbids variable length array ‘myArray’ [-Wvla]
To make the diagnostic be an error, for either compiler, pass -Werror=vla.
Simply plugging the snippets you posted into IDEone, without putting the array declaration into a function, I get
prog.cpp:12:39: error: array bound is not an integer constant before ‘]’ token
Adding a main() function around it results in success, as you observed.
Since C++11 doesn't allow for array declarations that are legal in main but not namespace scope, and that is a property of VLAs, it is reasonable to conclude that is what you are seeing.
Update: courtesy Coliru.org, the message from Clang is
main.cpp:12:9: error: variable length array declaration not allowed at file scope
So that's fairly definite.
Use these options:
-Wvla to warning vla uses
-Werror=vla to consider vla an error.
This works in both the clang and gcc compilers.