Semantics of MODIFY_EXPR with CONSTRUCTOR rhs

[Gabriel Dos Reis]

Laurent GUERBY <laurent@guerby.net> writes:

| Source from the ACATS testcase:
|      TEST ( "C52010A" ,  "CHECK THAT RECORD ASSIGNMENTS USE ""COPY""" &
|                          " SEMANTICS" );
| 
|      DECLARE
|           TYPE  REC  IS
|                RECORD
|                     X , Y  :  INTEGER ;
|                END RECORD;
|           R  :  REC ;
|      BEGIN
| 
|           R  :=  ( 5 , 8 ) ;
|           R  :=  ( X => 1 , Y => R.X ) ;
|           IF  R  /=  ( 1 , 5 )  THEN
|                FAILED ( "WRONG VALUE  (1)" );
|           END IF;
| 
| There's nothing "undefined" in Ada in the second assignment, and that's
| what the test is checking.

There are two issues, made distinct in RTH's message:

  (1) initialization
  (2) assignment.

My comments was made in the context of C99 semantics.
Assignment uses a copy.  Initialization with self-reference may have
indeterminate value.

Presumably, your Ada testcase expects copy, which agrees with C99
assignments semantics.

| Laurent
| 
| On Mon, 2004-08-02 at 10:15, Gabriel Dos Reis wrote:
| > | On Sun, Aug 01, 2004 at 11:20:06PM -0400, Richard Kenner wrote:
| > | > Suppose we have this in .t03.original:
| > | > 
| > | >   r = {.x=5, .y=8};
| > | >   r = {.x=1, .y=r.x};
| > | > 
| > | > Is the second statement valid?
| > 
| > The second statement is valid.  The syntactic and grammatical validity
| > is no valid different from the situation 
| > 
| >    struct S {
| >       void* data;
| >    };
| > 
| >    strust S s = { &s.data };
| > 
| > | ...
| > | > What's supposed to be happening here?
| > 
| > My understanding is that it is a behvaiour unspecified by the C99
| > standard, 6.7.8 Initialization:
| > 
| >        [#23] The order in which any side effects  occur  among  the
| >        initialization list expressions is unspecified.130)
| > 
| > Footnote 130 says:
| > 
| >        130In  particular, the evaluation order need not be the same
| >           as the order of subobject initialization.
| > 
| > 
| > I would suggest we warn user, and let optimizer decides ;-)

-- Gaby