[Bug c/24016] New: Missing "operation on xxx may be undefined" on obvious undefined code

[Bug c/24016] New: Missing "operation on xxx may be undefined" on obvious undefined code

[pinskia at gcc dot gnu dot org]

Take the following example:
void f(int *a)
{
  *a++ = __extension__ ({ int bb = *a; bb; });
}
---
We don't warn for the operation on a.  This is most likely we don't look into a BLOCK or a statement list, 
I don't know which one.  If I remove the declation of bb, it works, so I am going to assume we don't 
look into BLOCKs.

This was reduced from the following code with glibc and -O1:
#include <ctype.h>
void strtolower(char *data) { while (*data != '\0') *data++ = tolower(*data); }

-- 
           Summary: Missing "operation on xxx may be undefined" on obvious
                    undefined code
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: enhancement
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/24016] Missing "operation on xxx may be undefined" on obvious undefined code

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-09-22 17:24 -------
Subject: Re:  New: Missing "operation on xxx may be undefined"
 on obvious undefined code

On Thu, 22 Sep 2005, pinskia at gcc dot gnu dot org wrote:

> Take the following example:
> void f(int *a)
> {
>   *a++ = __extension__ ({ int bb = *a; bb; });
> }

I'm not convinced this is undefined: statement expressions act like 
(inline) function calls for the purpose of sequence point rules so the 
execution of the statement expression suspends the execution of the rest 
of the surrounding expression and there are sequence points at the 
beginning and end of the statement expression.

It is, however, at least unspecified order of evaluation and a warning 
here would still make sense.



-- 


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