This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Assignment operator


Mike Stump writes:
 > > From: Zoltan Kocsi <zoltan@bendor.com.au>
 > > Date: Wed, 13 Oct 1999 14:42:05 +1000 (EST)
 > 
 > > Here's part of the reply I got from Thomas MacDonald <tam@sgi.com>
 > > in the C Standard Committe. (You can have the full story, if you 
 > > want it.)
 > >  
 > >  : A careful reading of the C Standard clearly does *not* require
 > >  : re-reading the lvalue for a statement such as:
 > >  : 
 > >  :    a = b = c;
 > 
 > In C (last I knew) b=c isn't an lvalue, so I don't have any clue what
 > you two were talking about.  
 
On one hand, I was quoting Thomas MacDonald, member of C Standard
Committe, explaining the behaviour of the C assignment operator. 
 
 > a is an lvalue, but it isn't read.  So it
 > it pointless to talk about the re-read of a. 
 
This is true, we are talking about the re-read of b.
 
 > Also, in standard C, b
 > is not read, so it is pointless to talk about a re-read of b.
 
Try reading the part I included from Thomas MacDonald again. 
Especially the last paragraph of it. In essence, he says:

 In the above expression, with 'b' being a volatile object, the 
 C standard allows the compiler to assign to 'a' either the value it
 wrote to 'b' or, if it feels like, the value it can retrieve by
 reading 'b'. 

In C terms it means that
 
    a = b = c; 
 
can legally be compiled to either

    b = c;
	a = b;
	
or

   tmp = c;
   b = tmp;
   a = tmp;
   
Or, in general

  ( b = c )
  
can legally be compiled to either

  ( b = c, b )
or
  ( tmp = c, b = tmp, tmp )
   
The C standard grants this freedom to the compiler *regardless* of the 
volatile qualifier of b. However, if b is not volatile then the result 
is guaranteed to be be the same (type conversion issues aside).
   
If you don't agree with the above, you should argue with the C Standard
Commitee and not me. All I'm asking for is a compiler switch which would 
let me choose between the two interpretations. The rest is just icing.

I have also stated that I personally prefer the second interpretation
and that I believe that the spirit of the K&R book does too. In this
point you can argue with me, but unfortunately that seems to be the 
only issue in which we agree, actually :-) 

Regards,

Zoltan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]