warning: operation on 'zero' may be undefined

[Nathan Sidwell]

Paul Schlie wrote:
> Thanks, reviewed the faq, unfortunately question 3.3 specifies
> 
>  int i = 3 ;
>  i = i++ ;
> 
> as having undefined behavior, erroneously referencing
> 
>  a[i] = i++ ;
> 
> as being similarly undefined, which it is; but that's because the value
> of the index i is ambiguous as it's value is sensitive to the order
> of lhs/rhs evaluation; which i = i++ is not.
you do not understand. It is not undefined due to the ambiguity of ordering,
it is undefined because the constraint you later quoted is not maintained.

> And ironically, the ANSI/ISO C specification of a sequence point referred
> to in question 3.8 as being:
> 
>    "Between the previous and next sequence point an object shall have its
>     stored value modified at most once by the evaluation of an expression.
>     Furthermore, the prior value shall be accessed only to determine the
>     value to be stored."
> 
> Would seem to even further disambiguates the expression like i = ++i if i
> were declared as volatile, as it specifies that i will be at most read and
> written once, therefore:
> 
>  volatile int i = 3 ;
>  i = ++i ;

this is undefined.  a volatile does not get you a get-out-of-undefined-effect-free
card.  All the standard says about volatile
is that the store will have made it to the external environment of
the abstract machine by the following sequence point.  What the 'external
environment' is is implementation defined.

Please go and ask in compl.lang.c if you are still unconvinced about
the undefinedness of all this stuff.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk