UB question

[Michael Foukarakis]

Hello,

I've been working on a simulation project with a friend for the past
weeks, and we're making extensive use of BCD arithmetic (this is not
directly relevant, unless the discussion takes us there..). Last night
my buddy came up with this somewhere in her code:

while (i--)
*fp++ = *fp >> 4;

and I'm a little confused, because GCC says:

addcycle.c:109: warning: operation on 'fp' may be undefined

but it looks well-defined to me, albeit confusing.

What's your opinions? Can anyone definitively say whether this invokes
undefined behaviour?

Thanks in advance.

 

[Ike Naar]

while (i--)
*fp++ = *fp >> 4;

The behaviour is undefined; imagine two possible scenarios:
a) dereference fp in left part, increment fp, dereference fp in right part
b) dereference fp in right part, dereference fp in left part, increment fp

You could do this, though:

while (i--)
*fp++ >>= 4;

 

[Tim Rentsch]

Hello,

I've been working on a simulation project with a friend for the past
weeks, and we're making extensive use of BCD arithmetic (this is not
directly relevant, unless the discussion takes us there..). Last night
my buddy came up with this somewhere in her code:

while (i--)
*fp++ = *fp >> 4;

and I'm a little confused, because GCC says:

addcycle.c:109: warning: operation on 'fp' may be undefined

but it looks well-defined to me, albeit confusing.

What's your opinions? Can anyone definitively say whether this invokes
undefined behaviour?

Adding a redundant set of parentheses to emphasize grouping, the
expression in question is

*(fp++) = *fp >> 4;

There are two accesses to 'fp'. The left one increments 'fp' (and
returns the old value); the right one is an ordinary read access.
Question: Does the increment operation of the incrementing access
complete before or after the other (pure read) access? The Standard
doesn't prescribe any ordering between the two (since the accesses
are independent subexpressions and there are no sequence points
within the containing expression). So, this combination transgresses
a Standard requirement against independent reads and writes in the
same expression. Intuitively, because we don't know whether the
increment is done before or after the read access, that pretty much
kills any chance that the result will be useful, and so the Standard
rules it out-of-bounds. (The exact phrasing in the current standard
is "Furthermore, the prior value shall be read only to determine the
value to be stored." The pure read access is independent of the
modifying access; hence it violates this rule.) Make sense?

The given assignment expression is unquestionably undefined behavior.

 

[Michael Foukarakis]

Adding a redundant set of parentheses to emphasize grouping, the
expression in question is

    *(fp++) = *fp >> 4;

There are two accesses to 'fp'.  The left one increments 'fp' (and
returns the old value);  the right one is an ordinary read access.
Question:  Does the increment operation of the incrementing access
complete before or after the other (pure read) access?  The Standard
doesn't prescribe any ordering between the two (since the accesses
are independent subexpressions and there are no sequence points
within the containing expression).  So, this combination transgresses
a Standard requirement against independent reads and writes in the
same expression.  Intuitively, because we don't know whether the
increment is done before or after the read access, that pretty much
kills any chance that the result will be useful, and so the Standard
rules it out-of-bounds.  (The exact phrasing in the current standard
is "Furthermore, the prior value shall be read only to determine the
value to be stored."  The pure read access is independent of the
modifying access;  hence it violates this rule.)  Make sense?

After letting it sink for a moment (read: more than a few minutes), it
does. Thanks.