From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11678 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Documentation of memcpy and undefined behavior in memset Date: Thu, 6 Jul 2017 18:29:43 +0200 Message-ID: <20170706162943.GA10974@port70.net> References: <0F9B48AD-C5B3-44B6-8D82-0985CF8604A0@trust-in-soft.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1499358598 10005 195.159.176.226 (6 Jul 2017 16:29:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Jul 2017 16:29:58 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) To: musl@lists.openwall.com Original-X-From: musl-return-11691-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 06 18:29:54 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dT9f6-0002IO-Ep for gllmg-musl@m.gmane.org; Thu, 06 Jul 2017 18:29:52 +0200 Original-Received: (qmail 13451 invoked by uid 550); 6 Jul 2017 16:29:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13425 invoked from network); 6 Jul 2017 16:29:55 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <0F9B48AD-C5B3-44B6-8D82-0985CF8604A0@trust-in-soft.com> Xref: news.gmane.org gmane.linux.lib.musl.general:11678 Archived-At: * Pascal Cuoq [2017-07-06 14:15:25 +0000]: >=20 > s[0] =3D s[n-1] =3D c; >=20 > https://git.musl-libc.org/cgit/musl/tree/src/string/memset.c?id=3Da08910f= c2cc739f631b75b2d09b8d72a0d64d285#n14 >=20 > I think this is undefined because i =3D i++;, which is equivalent to i = =3D i =3D i + 1;, is the canonical example for the =E2=80=9Cunsequenced sid= e-effect in expression=E2=80=9D undefined behavior(*), and what makes this = latter example undefined is the =E2=80=9Ci =3D i =3D=E2=80=9D part, not the= =E2=80=9Ci + 1=E2=80=9D part. Musl's =E2=80=9Cs[0] =3D s[n-1] =3D=E2=80=9D= is identical to that when n =3D=3D 1. > The same problem occurs in the next lines of memset for other values of n. >=20 i think it's wrong to say that i =3D i++ is equivalent to i =3D i =3D i+1, since i=3Di+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 =3D i =3D 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.