[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170706192831.GC10974@port70.net>
Date: Thu, 6 Jul 2017 21:28:32 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Bartosz Brachaczek <b.brachaczek@...il.com>
Subject: Re: Documentation of memcpy and undefined behavior in memset
* Leah Neukirchen <leah@...u.org> [2017-07-06 21:10:31 +0200]:
> Bartosz Brachaczek <b.brachaczek@...il.com> writes:
>
> > On 7/6/2017 6:23 PM, Rich Felker wrote:
> >> I think you're correct, at least under a pessimistic interpretation of
> >> the standard. I can't find where they actually define "modifies", and
> >> you could argue that assignment of the same value twice "modifies" the
> >> object at most once, but I don't like relying on that kind of
> >> ambiguity and it's easy enough to fix just by adding a sequence point.
> >
> > I don't have a copy of C11, but N1570 reads in a note to 3.1:
> >
> >> ‘‘Modify’’ includes the case where the new value being stored is the
> >> same as the previous value.
>
> C11 also specifies a sequence for assignment (6.5.16.3):
>
> > The side effect of updating the stored value of the left operand is
> > sequenced after the value computations of the left and right
> > operands.
yes, unfortunately the value computation of the right
operand can be unsequenced wrt the side effect of the
right operand..
but since expression evaluation with side effects is
not specified in great detail it's hard to tell.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
