[Coco] Found strangeness in C compiler (bug)

[Mathew Boytim]

 Yeah there are areas in the spec which are undefined or implementation dependent which I think would be better to be defined although I can often understand why they're not.  For example a right shift of a signed quantity may be arithmetic or logical it is implementation dependent.
In my experience there are a lot of gray areas in c.  We (programmers) get away with an awful lot which is not strictly legal.  We use IAR for a lot of embedded development and the IAR compiler/optimizer is pretty kind in that it seems to do things as you would want or expect but aren't strictly legal/defined.  On the other hand I find the gcc compiler/optimizer to be 'greedy' in that it takes advantage of the strict definition when it wants to.  I frequently encounter programmers complaining of bugs in gcc because things that they routinely do with IAR don't work with gcc - but in all cases gcc has been right.
Matt

    On Tuesday, May 21, 2019, 8:16:35 AM EDT, Allen Huffman <alsplace at pobox.com> wrote:  
 
 
On May 21, 2019, at 7:12 AM, Mathew Boytim via Coco <coco at maltedmedia.com> wrote:
I agree the result is undefined.  This is what gcc has to say
main.c:7:4: warning: operation on ‘da’ may be undefined [-Wsequence-point] *da++ = *dN++ * v - *da; // this is correct as the increment should happen after the assignment  ~~^~

The standard doesn't say when the pointer is incremented, it only says where the result will be stored so you can't say "the increment will happen after the assignment".  I have to agree that the behavior is not what I would expect but undefined is undefined.  Bottom line is that you can't do that and expect it to be predictable.
Matt


When I worked for Microware, we’d often receive customer support calls about the compiler doing something odd. We’d run it by the compiler group, and more often than not, they’d respond with the bit from the ANSI spec explaining that what the customer was doing was “undefined” and shouldn’t be done that way.
I find it interesting that many of these undefined things are finally getting defined in later versions of the spec (someone mentioned C 17).
 — Allen