2

C++ complains when you compare a pointer with an integer expect when the integer is zero (0). I found this out due to a bug in my program. Is there a way to forbid this / warn about it? There is already nullptr so I think (some_ptr == 0) is just source of bugs.

Ðаn
  • 10,934
  • 11
  • 59
  • 95
AdyAdy
  • 988
  • 6
  • 19
  • Options to control warnings are not part of the C++ specification, they're dependent on the particular compiler. So you need to say what compiler you're using. – Barmar May 25 '17 at 13:10
  • 7
    Why would `some_ptr == 0` be a source of bugs? `0` is a valid null pointer constant. It warns about other integers because they don't have a standard meaning when used as pointers, but `0` is very well defined. `nullptr` is a recent addition to the language, `NULL` and `0` have been the way it was done for many years. – Barmar May 25 '17 at 13:11
  • 4
    This is compiler specific, for g++ use `-Wzero-as-null-pointer-constant` – Richard Critten May 25 '17 at 13:14
  • @Barmar there was a defect report raised on the use of `0` see: http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#903 At compile time `0` can be resolved either as a pointer or as an integer constant producing function overload problems. – Richard Critten May 25 '17 at 13:18
  • @Barmar The "standard" answer is "What if 0 is a valid pointer on some systems?", but it is surreal of course nowadays... Other things, related to function overloads, are explained [here](https://stackoverflow.com/questions/13816385/what-are-the-advantages-of-using-nullptr). – Ivan Aksamentov - Drop May 25 '17 at 13:18
  • @Drop -- no, 0 is **never** a valid pointer; the language definition says that it is a null pointer. Yes, systems can have addressable memory at 0, but that doesn't change the language requirement. – Pete Becker May 25 '17 at 13:19
  • @PeteBecker Well, then the language requirement is silly and should be changed. – Ivan Aksamentov - Drop May 25 '17 at 13:31
  • @Barmar I changed an integer to a pointer-to-an-integer and refactored my code accordingly but forgot to change a (some_var == 0) to (*some_var == 0), that was the source of my bug. I found it weird that the compiler didn't say anything about it. – AdyAdy May 25 '17 at 13:39
  • 1
    @Richard Critten Yes, I'm using g++, thank you! – AdyAdy May 25 '17 at 13:44
  • 1
    @Drop If memory serves, the integer literal `0` is a null-pointer constant (whatever its actual value is), but for example `(1 - 1)` could yield an actual pointer with value zero on such a system. – Quentin May 25 '17 at 14:27
  • 1
    Given overloads: `void f(int)` and `void f(int*)` then: `f(1)` calls `f(int)`, `f(0)` calls `f(int*)`, and `f(1-1)` calls `f(int)` now add templates into this mess - lets stop using `0` and use `nullptr`. – Richard Critten May 25 '17 at 14:33
  • Not a problem if you just do `if(!some_ptr) { /* ptr is null */}`. – Galik May 25 '17 at 14:44
  • @Drop -- changing the rule that 0 is a null pointer constant would break **lots** of existing code. That's been the rule since the olden days of K&R C. – Pete Becker May 25 '17 at 15:20
  • You could do something about it, but then you'd kill everything that relies on `NULL`, on every compiler that doesn't explicitly specify it as `(void *) 0` instead of just `0`. Not a problem in modern C++, but it's a problem whenever you use anything that requires any C code. – Justin Time - Reinstate Monica May 25 '17 at 19:24

0 Answers0