Unusual warning

[Arash Partow]

Hi all,

I have the following bit of code:

int main()
{
unsigned int a = 0xAAAAAAAA;
unsigned int g = 0x55555555;
a = (a <<= 1) ^ g;
return 0;
}

GCC outputs the following warning:
code.c: In function `main':
code.c:5: warning: operation on `a' may be undefined


I was wondering if anyone could explain why "a" may be undefined?
Is this referenced somewhere in the cfaq?




Arash Partow
__________________________________________________
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
http://www.partow.net

 

[Richard Heathfield]

Arash Partow said:

Hi all,

I have the following bit of code:

int main()
{
unsigned int a = 0xAAAAAAAA;
unsigned int g = 0x55555555;
a = (a <<= 1) ^ g;
return 0;
}

GCC outputs the following warning:
code.c: In function `main':
code.c:5: warning: operation on `a' may be undefined


I was wondering if anyone could explain why "a" may be undefined?

Because you're violating a "shall" that is not a constraint, to wit
3.3(2):

"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."

Is this referenced somewhere in the cfaq?

Not your exact expression, obviously, but the following URL:

<http://c-faq.com/expr/seqpoints.html>

covers the basic problem.

I would guess that the following modification still expresses your
intent and yet is well-defined:

a = (a << 1) ^ g;

 

[Eric Sosman]

Hi all,

I have the following bit of code:

int main()
{
unsigned int a = 0xAAAAAAAA;
unsigned int g = 0x55555555;
a = (a <<= 1) ^ g;
return 0;
}

GCC outputs the following warning:
code.c: In function `main':
code.c:5: warning: operation on `a' may be undefined


I was wondering if anyone could explain why "a" may be undefined?

The variable `a' is well defined, but the operation
on it is not. The fifth line tries to modify `a' twice
without an intervening sequence point. That's undefined
behavior. Perhaps you actually meant

a = (a << 1) ^ g;

.... which suffers from no objectionable udnfenideenss.

Is this referenced somewhere in the cfaq?

Yes. Questions 3.1, 3.2, 3.3, and 3.3b all address
this issue.