[Bug c/47931] New: missing -Waddress warning for comparison with NULL

[Bug c/47931] New: missing -Waddress warning for comparison with NULL

[msebor at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47931

           Summary: missing -Waddress warning for comparison with NULL
           Product: gcc
           Version: 4.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: msebor@gmail.com


The -Waddress option causes gcc to emit a warning for suspicious tests of
addresses of functions and objects. The patch that implemented the feature and
the current test for it indicate that the diagnostic is intended to include the
NULL pointer constant. However, gcc fails to diagnose the pointless comparison
against NULL in the test case below.

http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00972.html 
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/Walways-true-1.c 

I note that Wstring-literal-comparison-1.c test exercises the ability to
diagnose comparisons of string literals against 0 while at the same time
allowing such comparisons against null pointer constant. Perhaps this feature
conflicts with the ability to issue warnings for constants of other types.
Alternatively, it's possible that the ability to avoid a diagnostic when a null
pointer constant is used is deliberate.

This is a request to either issue the warning in all cases, or to document the
existing behavior so that it can be relied on with some assurance that it will
continue to work this way in future versions of gcc.

$ cat -n t.c && gcc -Waddress -c t.c
     1  #define NULL (void*)0
     2
     3  int i;
     4
     5  int f() { return &i != 0; }
     6  int g() { return &i != NULL; }
t.c: In function ‘f’:
t.c:5: warning: the address of ‘i’ will never be NULL

[Bug c/47931] missing -Waddress warning for comparison with NULL

[msebor at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47931

--- Comment #1 from Martin Sebor <msebor at gmail dot com> 2011-02-28 19:38:15 UTC ---
To add a suggested solution to my report: Since many (most?) comparisons will
be against NULL which can be defined as either 0 or (void*)0 I think it would
be best to diagnose both forms. To make it possible to easily silence the
warning I suggest not diagnosing cases of comparison against a null pointer
constant of the same type. I.e., like so:

  int i;

  if (&i);               // warning
  if (&i == 0);          // warning
  if (&i == (void*)0);   // warning
  if (&i == (int*)0);    // NO warning

[Bug c/47931] missing -Waddress warning for comparison with NULL

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47931

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-03-01 09:05:13 UTC ---

PR 36299 asks to not warn for (&a == 0). Ideally, we should allow users to
workaround the warning by using a pointer cast on the variable but warn for 
(void *)0. I think this would be a reasonable middle-ground.

But at the end, someone has to dig in the code and implement whatever he can.
This part of the C FE is not very pretty.

[Bug c/47931] missing -Waddress warning for comparison with NULL

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47931

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.03.01 10:16:45
     Ever Confirmed|0                           |1

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-01 10:16:45 UTC ---
Confirmed.