Re: tricky assignment statemenent

From: Christian Bau (christian.bau_at_cbau.freeserve.co.uk)
Date: 01/04/05 

Date: Tue, 04 Jan 2005 18:07:59 +0000

In article <pan.2005.01.04.16.10.22.281000@netactive.co.uk>,
 Lawrence Kirby <lknews@netactive.co.uk> wrote:

> On Fri, 31 Dec 2004 05:50:38 +0000, Joona I Palaste wrote:
>
> > Ike Naar <nospam@nospam.invalid> scribbled the following:
> >> Consider the following code:
>
> ...
>
> >> void f(struct s * q)
> >> {
> >> struct s * p = malloc(sizeof *p);
> >> if (p != 0)
> >> {
> >> p = p->next = q; /* is this safe? */
> >> }
> >> }
> >
> >> In the context given above, is the statement "p = p->next = q;"
> >> safe and equivalent to "p->next = q; p = q;"
> >> or does it invoke undefined behaviour because p is modified and
> >> dereferenced at the same time?
> >
> > I would consider it undefined behaviour, as there is no sequence point
> > between the operations "p=p->next" and "p->next=q" in the code.
>
> However the standard says "Furthermore, the prior value shall be read only
> to determine the value to be stored." In p = p->next = q the value
> assigned to p is the result of the expression p->next = q. In the abstract
> machine this expression must be evaluated fully in order to generate the
> value to be assigned. The access to p in p->next is part of that
> evaluation so it is very much being read in order to determine the new
> value. Before you start formulting your objections to this consider
> carefully the statements in the standard (5.1.2.3):

There are two assignments here. In one assignment, p is modified. The
prior value of p is arguably used to determine the new value stored into
p, as you explained, but it is _also_ read to determine at which memory
location the second assignment will happen, so it is not _only_ read to
determine the value stored, therefore undefined behavior.

Relevant Pages

  • Re: Does this cause undefined behaviour?
    ... > But I am not sure this is the reason. ... >> assignment reads the value of i outside of the expression on the LHS ... > The value assigned is not necessarily the prior value, ... EXACT quote from paragraph 2 of section 6.5 of the C standard: ...
    (comp.lang.c)
  • Re: Questions about C1x
    ... POSIX uses the C standard definition, ... described here and the ISO C standard is unintentional. ... On implementations that do not detect output string ...
    (comp.std.c)
  • Re: aes decrypt encrypt
    ... overlook more departments. ... They are founding towards magic, prior to standard, in the light of ...
    (sci.crypt)
  • Re: removing a loop cause it to go at half the speed?
    ... We can agree that undefined behaviour is "behavior, ... for which this International Standard imposes no requirements" from ... since what is a trap on one implementation could be valid on another. ... which accesses an uninitialized int is strictly non-portable, ...
    (comp.lang.c)
  • Re: memory allocation question
    ... > | Unless there's wording in the standard guaranteeing portabilty, ... Only some cases of undefined behaviour ... program construct or erroneous data, ... International Standard imposes no requirements. ...
    (alt.comp.lang.learn.c-cpp)