Undefined behaviour when modifying the result of an assignment operator

[Andy Lomax]

The C99 standard contains various statements like this one (in this
case, 6.5.16, assignment operator):

If an attempt is made to modify
the result of an assignment operator or to access it after the next sequence point, the
behavior is undefined.

What does this actually mean? Can anyone give me a code example that
leads to undefined behaviour?

Cheers

AL

 

[Kenny McCormack]

The C99 standard contains various statements like this one (in this
case, 6.5.16, assignment operator):


What does this actually mean? Can anyone give me a code example that leads
to undefined behaviour?

I would assume something like: (a=b)=c;

 

[Andy Lomax]

I would assume something like: (a=b)=c;

I don't think this is what they mean - this would be a semantic error
(since the result of (a=b) isn't an lvalue), so the second assignment
is invalid, rather than having undefined behaviour.

It beats me how you can attempt to modify something which isn't an
lvalue without it being an error.

Cheers

AL

 

[lawrence.jones]

What does this actually mean? Can anyone give me a code example that
leads to undefined behaviour?

struct { int a[2]; } s, t;
int *p;

(s = t).a[0] = 3; // attempting to modify the result of an assignment op.
p = (s = t).a;
p[0]; // attempting to access the result after the next s.p.

-Larry Jones

Hmph. -- Calvin

 

[Andy Lomax]

What does this actually mean? Can anyone give me a code example that
leads to undefined behaviour?

struct { int a[2]; } s, t;
int *p;

(s = t).a[0] = 3; // attempting to modify the result of an assignment op.
p = (s = t).a;
p[0]; // attempting to access the result after the next s.p.

-Larry Jones

Hmph. -- Calvin

Very interesting - gcc/C90 gives a syntax error ('invalid use of
non-lvalue array for 'p=(s=t).a'), but gcc/C99 compiles Ok, but I
don't understand why.

The spec says:

An
assignment expression has the value of the left operand after the assignment, but is not an
lvalue.

So how is it possible to write '(s=t).a[0] = 3'?

Secondly, surely there's no problem accessing the result of an
assignment op *after* the next sequence point. Wouldn't the problem
arise if it was accessed *before* the next sequence point, which is
potentially before the update side-effect has taken place?

Cheers

AL

 

[Keith Thompson]

If an attempt is made to modify the result of an assignment
operator or to access it after the next sequence point, the
behavior is undefined.

What does this actually mean? Can anyone give me a code example that
leads to undefined behaviour?

struct { int a[2]; } s, t;
int *p;

(s = t).a[0] = 3; // attempting to modify the result of an assignment op.
p = (s = t).a;
p[0]; // attempting to access the result after the next s.p.

Very interesting - gcc/C90 gives a syntax error ('invalid use of
non-lvalue array for 'p=(s=t).a'), but gcc/C99 compiles Ok, but I
don't understand why.

The spec says:

An assignment expression has the value of the left operand after the
assignment, but is not an lvalue.

So how is it possible to write '(s=t).a[0] = 3'?

The result of the assignment expression is not an lvalue, but ...

The expression (s=t) yields a value (not an lvalue) of the above
struct type.

(s=t).a is of type int[2], which is implicitly converted to int*.
(This issue wouldn't occur if it were of type const int*, but the
language doesn't say there's a const, so there isn't.

(s=t).a[0] is therefore an lvalue of type int. There's no problem if
you want to read this value, but attempting to modify it invokes
undefined behavior.

Secondly, surely there's no problem accessing the result of an
assignment op *after* the next sequence point. Wouldn't the problem
arise if it was accessed *before* the next sequence point, which is
potentially before the update side-effect has taken place?

A struct assignment copies a struct value to a struct object and
yields the assigned value. Imagine that this value is stored in some
temporary location that no longer exists after the assignment (or
after the next sequence point). The assignment
p = (s = t).a;
grabs and saves the address of something within that temporary
storage. After the next sequence point, the storage should be assumed
to be gone, so any attempt to examine it invokes undefined behavior.

If you attempt to do something similar before the next sequence point,
either it's ok (because the temporary is still there), or it invokes
undefined behavior because of the other existing rules.

Note that something like this:

x = y;
x;

does not access the result of the assignment; it access the value of
x, which was set by an assignment that was completed before the
previous sequence point. The "result of the assignment" is a
temporary value that in most cases cannot be accessed as an object.
The obscure case above involving assignments of structures containing
arrays is, as far as I know, the only kind of thing that can cause
this problem.

 

[Christian Bau]

I don't think this is what they mean - this would be a semantic error
(since the result of (a=b) isn't an lvalue), so the second assignment
is invalid, rather than having undefined behaviour.

It beats me how you can attempt to modify something which isn't an
lvalue without it being an error.

Yes, it is difficult. This is untested, and you may have to change it,
but you'll get the idea.

typedef struct { int x; int a [3]; } mystruct;

mystruct x, y;

(x = y).a [2] = 0;

The result of an assignment operator is not an lvalue. However, if it is
a struct, then you can access the struct members. And if one struct
member is an array, you can access the array elements and that gives you
an lvalue. And _then_ you can attempt to modify that lvalue.

So why is this undefined behavior? I guess that first of all compiler
writers were complaining: "Am I supposed to generate code for such
braindamaged garbage code?" I think your average compiler writer would
rather poke anyone writing that kind of code with pointy sticks until
they change their code, rather than producing code for it.

Second, the result of an assignment is not the left hand side - it is a
value that is equal to the left hand side. So what is supposed to be
changed by the "= 0" assignment? That's why it is undefined behavior.

 

[Andy Lomax]

The result of the assignment expression is not an lvalue, but ...

The expression (s=t) yields a value (not an lvalue) of the above
struct type.

(s=t).a is of type int[2], which is implicitly converted to int*.
(This issue wouldn't occur if it were of type const int*, but the
language doesn't say there's a const, so there isn't.

(s=t).a[0] is therefore an lvalue of type int. There's no problem if
you want to read this value, but attempting to modify it invokes
undefined behavior.

Thanks guys. It hadn't occurred to me that a value might contain an
lvalue.

AL