443,310 Members | 1,466 Online
Need help? Post your question and get tips & solutions from a community of 443,310 IT Pros & Developers. It's quick & easy.

# Undefined behaviour when modifying the result of an assignment operator

 P: n/a The C99 standard contains various statements like this one (in this case, 6.5.16, assignment operator): If an attempt is made to modifythe result of an assignment operator or to access it after the next sequence point, thebehavior is undefined. What does this actually mean? Can anyone give me a code example that leads to undefined behaviour? Cheers AL Nov 14 '05 #1
7 Replies

 P: n/a In article , Andy Lomax wrote:The C99 standard contains various statements like this one (in thiscase, 6.5.16, assignment operator):If an attempt is made to modify the result of an assignment operator orto access it after the next sequence point, the behavior is undefined.What does this actually mean? Can anyone give me a code example that leadsto undefined behaviour? I would assume something like: (a=b)=c; Nov 14 '05 #2

 P: n/a On Mon, 20 Jun 2005 15:21:47 GMT, ga*****@yin.interaccess.com (Kenny McCormack) wrote: In article ,Andy Lomax wrote:The C99 standard contains various statements like this one (in thiscase, 6.5.16, assignment operator):If an attempt is made to modify the result of an assignment operator orto access it after the next sequence point, the behavior is undefined.What does this actually mean? Can anyone give me a code example that leadsto undefined behaviour?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 Nov 14 '05 #3

 P: n/a Andy Lomax wrote [quoting the C standard]:If an attempt is made to modifythe result of an assignment operator or to access it after the next sequence point, thebehavior 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. -Larry Jones Hmph. -- Calvin Nov 14 '05 #4

 P: n/a On Mon, 20 Jun 2005 16:13:01 GMT, la************@ugs.com wrote: Andy Lomax wrote [quoting the C standard]:If an attempt is made to modifythe result of an assignment operator or to access it after the next sequence point, thebehavior 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.-Larry JonesHmph. -- 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: Anassignment expression has the value of the left operand after the assignment, but is not anlvalue. 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 Nov 14 '05 #5

 P: n/a Andy Lomax writes: On Mon, 20 Jun 2005 16:13:01 GMT, la************@ugs.com wrote:Andy Lomax wrote [quoting the C standard]:If an attempt is made to modify the result of an assignmentoperator or to access it after the next sequence point, thebehavior 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 theassignment, 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. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #6

 P: n/a In article , Andy Lomax wrote: On Mon, 20 Jun 2005 15:21:47 GMT, ga*****@yin.interaccess.com (Kenny McCormack) wrote:In article ,Andy Lomax wrote:The C99 standard contains various statements like this one (in thiscase, 6.5.16, assignment operator):If an attempt is made to modify the result of an assignment operator orto access it after the next sequence point, the behavior is undefined.What does this actually mean? Can anyone give me a code example that leadsto undefined behaviour?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. 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. Nov 14 '05 #7

 P: n/a On Mon, 20 Jun 2005 23:55:14 GMT, Keith Thompson wrote: The result of the assignment expression is not an lvalue, but ...The expression (s=t) yields a value (not an lvalue) of the abovestruct 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 thelanguage 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 ifyou want to read this value, but attempting to modify it invokesundefined behavior. Thanks guys. It hadn't occurred to me that a value might contain an lvalue. AL Nov 15 '05 #8

### This discussion thread is closed

Replies have been disabled for this discussion.