Hacker News Reader

Comment by archangel_one | Hacker News Reader

The article implies to me that the third bug (passing 0.5 to sleep() ) is not caught by gcc. Does anyone know if this is the case? It doesn't seem excessively hard to produce a warning about shortening like that - the first two seem more subtle, but that one less so. I don't have gcc on this machine to check it, but VC++ certainly does emit a warning for that kind of thing.

View on HN

GCC definitely has a warning for 0.5 -> int (likely -Wconversion, but I've not checked). It also has a warning for setting a pointer to "false" (-Wconversion-null). However, turning that warning on in a codebase where every warning breaks the build was challenging because of false positives. We're able to remove false positives and narrow the scope of the warning to just the buggy code in many cases with Clang, and that allows us to turn these warnings on much more aggressively.

When is assigning a pointer to be boolean false intentional and correct?

I think the -Wconversion-null warnings are the other way around:

    int i = NULL;

Because of C++'s conflation of NULL and 0 (and now C++0x's nullptr).

Most of the cases we ran into were metaprogramming techniques which test whether an expression is a valid null pointer constants. These got innocently applied to 'false' and trigger the warning needlessly.

Done that before...had a variable that was formerly an int:

  int foo = 0;

But got changed into a non-integral type:

  Thing foo = 0;

Turns out Thing had a copy constructor roughly like:

  Thing::Thing(Thing* old)
      : field(old->field)
  {
  }

Needless to say, my program was not very happy.

Isn't the real bug in the example where the bool was assigned to the pointer that a pointer was used where it should have been a reference?

Google's C++ style guide discourages the use of references altogether.

Reply on news.ycombinator.com