Re: [C, C++] "(a=b) = c;" Illegal or Undefined?
From: Leor Zolman (leor_at_bdsoft.com)
Date: 01/23/04
- Next message: Jumbo: "Re: Container question"
- Previous message: Tom Junior: "Re: Void Pointer Question -- Accept any datatype."
- In reply to: Leor Zolman: "Re: [C, C++] "(a=b) = c;" Illegal or Undefined?"
- Next in thread: Josh Sebastian: "Re: [C, C++] "(a=b) = c;" Illegal or Undefined?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 23 Jan 2004 19:01:04 GMT
On Thu, 22 Jan 2004 20:54:29 GMT, Leor Zolman <leor@bdsoft.com> wrote:
>On 22 Jan 2004 12:21:57 -0800, desh_bakth@yahoo.com (Anand Hariharan)
>wrote:
>>He demonstrates that it compiles, hence legal. The program then
>>crashes, and he argues thus: "There are two sequence points upon
>>which there are multiple assignments to 'a'. Hence this is an
>>instance of undefined behaviour."
>
>I don't know; an expression within parens would have to be evaluated
>_before_ it can be assigned to, no? Maybe that's just too much common
>sense for my own good, but I'm not going to go looking this up in the
>Standard for fear of finding out otherwise ;-)
>
Turns out, that _was_ too much common sense for my own good. Calling
upon my trusty personal Standard interpreter, Dan Saks, I've been now
set straight, and have learned some interesting things...one of which
Dan himself was only made aware of recently WRT this issue.
The part that was "missing" in my mind was that the Standard strives
to express things in a way that allows the most flexibility of
implementation across disparate platforms, and the interesting
question here is to ask how a multi-processing platform might want to
deal with expressions such as
(a = b) = c; // let's just talk built-ins here
Assignment operators are concerned with the _address_ of their left
operand, not its value. The right-hand assignment op only needs to
know the _address_ of "a" in order to set out about its business, and
that can be determined at compile time (in a relative sort of way).
Thus, the lack of sequence points here frees up an optimizer to send
one subexpression to one processor, and the other to another. So in
fact the processor responsible for the right-hand assignment _might_
conclude its work before another processor completes evaluation of the
left-hand assignment.
Things get "more undefined" (so to speak) if there are other
side-effects involved, e.g.:
(a = b++) = c;
because (and this the thing Dan recently found out) some optimizers
look for the most complex subexpressions and evaluate them first, in
order to guarantee having the most free registers during those
evaluations (if it left the complex expressions for last, there might
be enough temporary results residing in registers at that moment to
make it impossible to do the remaining, complex task in the most
CPU-efficient way). So in the above trivial example the ramifications
might not come out, but somewhere they undoubtedly would.
I guess common sense doesn't count for much when dealing with issues
like these.
-leor
Leor Zolman
BD Software
leor@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html
- Next message: Jumbo: "Re: Container question"
- Previous message: Tom Junior: "Re: Void Pointer Question -- Accept any datatype."
- In reply to: Leor Zolman: "Re: [C, C++] "(a=b) = c;" Illegal or Undefined?"
- Next in thread: Josh Sebastian: "Re: [C, C++] "(a=b) = c;" Illegal or Undefined?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
