9

Neither g++ (4.4 and 4.6) nor clang++ (3.2) nor coverity, with -Wall and -Wextra (+ some others) or -Weverything respectively gives me a warning for the following code snippet:

class B {
    char *t2;
    char *t;

public:
    B() : t2(t), t(new char[100]) {}
};

I would at least expect a small warning about the usage of uninitialized (member-) variables.

Is there something I'm missing? Is this a wanted "no-warning"-scenario. I have (now had) at least one bug in my software which was hard to find.

EDIT: As can be read in this new question I realized that coverity warns about this problem in some cases.

Community
  • 1
  • 1
Patrick B.
  • 10,471
  • 7
  • 49
  • 85
  • afaik only code analysis tools like valgrind can issue warning in such cases – Piotr Tkaczyk Jan 03 '13 at 13:00
  • coverity is a static analyzer which finds gazillions of uninitialized usages of variables everywhere in the code, but not this one. This can only be the case because someone did not put the path-analysis on initializer-list. My question is, whether there is a good reason for that or not? – Patrick B. Jan 03 '13 at 13:04
  • If I did that, I would appreciate seeing a warning. – brian beuning Jan 03 '13 at 14:06

2 Answers2

6

There is no good reason not to issue a warning here.

G++ isn't smart enough to diagnose unintialized members in constructors, see http://gcc.gnu.org/PR2972

I have a work-in-progress patch to fix it which I hope to finish "some time this year"

Even with my patch I'm not sure G++ would warn, because t2 is initialized, but it's initialized to an indeterminate value. For the compiler to track that is not trivial, but should be possible (so I'm surprised even Coverity misses it.) Run-time tools such as valgrind get it right though.

When I revisit my patch I'll consider this case and see whether I can make it warn, without adding too much overhead (currently my patch checks whether members without an initializer would leave data uninitialized, to catch this I would need to also check members with an initializer and check whether that initializer relies on another member which isn't yet initialized, which would need to be checked for every member, which might have an effect on compilation speed for classes with lots of members.)

Jonathan Wakely
  • 153,269
  • 21
  • 303
  • 482
3

The C++ standard says that using uninitialized variables leads to undefined behaviour. It does not mandate that the compiler issue a diagnostic about it. So getting a warning or not is a QOI (Quality of Implementation) thing.

user93353
  • 12,985
  • 7
  • 50
  • 106
  • What you want to say is, that, e.g. gcc is warning about uninitialized local variable with -Wall and -O because "someone" added a warning for it, but no one yet added a one for my case? – Patrick B. Jan 03 '13 at 13:01
  • @PatrickB. I am saying that the compiler can exhibit the behaviour you describe while being standard compliant. But as you say this case was probably overlooked or may be warning about uninitialized member variables was prioritised as a feature different from warning about unitialized non-member vars. Don't really know. – user93353 Jan 03 '13 at 13:04
  • OK, that would confirm my theory about this thing. (PS: it wasn't me who downvoted, ppl downvote very fast and up-voting questions is rare...) – Patrick B. Jan 03 '13 at 13:07
  • In the case of Clang, adding this warning is on the TODO-list. – Hans W Jan 05 '13 at 16:59
  • @HansW can you point me to the entry of the TODO list? If available? – Patrick B. Jan 05 '13 at 17:45
  • 1
    @PatrickB.: I was thinking about the comment in [lib/Sema/SemaDeclCXX.cpp:2307](https://github.com/chapuni/clang/blob/release_32/lib/Sema/SemaDeclCXX.cpp#L2307). – Hans W Jan 05 '13 at 20:52