Once again bit by the "forgot to initialize" bug
Mark Oates

The code worked fine on one repo.

So I copied it over to a different repo, bit-for-bit it was exactly the same, and all of a sudden it doesn't work. An internal process was stopping prematurely.

It turns out I was aborting after checking the status of my FileDownloader.abort flag to see if the download should be aborted mid-transfer. Problem was that I had never set it true.

But a deeper problem was that I never initialized it. >:(

So I initialized it to false and it worked. :-/

Isn't there a compiler flag for that? >:(

Elias

I don't know about compiler flags. But in theory gcc/clang should already have all they need to check for uninitialized values after the constructor... I suppose one problem is if you have several constructors and some initialize and some do not.

My solution is to run through valgrind once a day - as long as your test tries to access the uninitialized variable at runtime it will cause an error.

Mark Oates

I mean, there's a flag that checks for the order of initialization:

src/gui/scaled_text.cpp:62:6: warning: field 'text' will be initialized after field 'font_color' [-Wreorder]

Surely there's a check that initialization occurred. :-/

Kitty Cat

Clang's static analyzer may help catch uninitialized use, which does much deeper checking of code flow. Problem is, when the code is spread around a bunch of sources and called at different times, it's difficult to tell per source file if something will used without initialization. That's why most compilers will only warn for local variables that aren't passed by reference somewhere.

Other than that, it needs run-time checking, which valgrind will do.

Edgar Reynaldo

If you use CB, there's a check box for "Effective C++" contributed by Scott Meyers. It may do what you want but I'm not sure. It enables so many warnings I just leave it unchecked.

Mark Oates

I guess I should say "member is present in the initialization list", and not "initialization occurred" to be more correct.

Thread #616756. Printed from Allegro.cc