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 = 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 = 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.