[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170706162943.GA10974@port70.net>
Date: Thu, 6 Jul 2017 18:29:43 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Documentation of memcpy and undefined behavior in memset
* Pascal Cuoq <cuoq@...st-in-soft.com> [2017-07-06 14:15:25 +0000]:
>
> s[0] = s[n-1] = c;
>
> https://git.musl-libc.org/cgit/musl/tree/src/string/memset.c?id=a08910fc2cc739f631b75b2d09b8d72a0d64d285#n14
>
> I think this is undefined because i = i++;, which is equivalent to i = i = i + 1;, is the canonical example for the “unsequenced side-effect in expression” undefined behavior(*), and what makes this latter example undefined is the “i = i =” part, not the “i + 1” part. Musl's “s[0] = s[n-1] =” is identical to that when n == 1.
> The same problem occurs in the next lines of memset for other values of n.
>
i think it's wrong to say that i = i++ is equivalent to i = i = i+1,
since i=i+1 is not the same as i++ (it is almost the same as ++i but
actually subtly different when considering sequencing evaluations so
such analogy is just confusing).
you can say that you think i = i = 0 is ub.
i think the key is that the value computation of an assignment
expression is not sequenced after its side effect (store) (note
that the value computations of the operands are sequenced before it),
so there are two unsequenced stores to the same object, this is not
very obvious from the text of the standard though.
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.
