From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11690 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 21:28:32 +0200 Message-ID: <20170706192831.GC10974@port70.net> References: <0F9B48AD-C5B3-44B6-8D82-0985CF8604A0@trust-in-soft.com> <20170706162353.GC1627@brightrain.aerifal.cx> <98d2e82c-1930-5dc2-2afa-bf6f4c9a8a50@gmail.com> <8760f5s7o8.fsf@gmail.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 1499369329 22285 195.159.176.226 (6 Jul 2017 19:28:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Jul 2017 19:28:49 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) Cc: Bartosz Brachaczek To: musl@lists.openwall.com Original-X-From: musl-return-11703-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 06 21:28:43 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 1dTCS8-0005OD-Dr for gllmg-musl@m.gmane.org; Thu, 06 Jul 2017 21:28:40 +0200 Original-Received: (qmail 18000 invoked by uid 550); 6 Jul 2017 19:28:44 -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 17979 invoked from network); 6 Jul 2017 19:28:43 -0000 Mail-Followup-To: musl@lists.openwall.com, Bartosz Brachaczek Content-Disposition: inline In-Reply-To: <8760f5s7o8.fsf@gmail.com> Xref: news.gmane.org gmane.linux.lib.musl.general:11690 Archived-At: * Leah Neukirchen [2017-07-06 21:10:31 +0200]: > Bartosz Brachaczek writes: >=20 > > 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: > > > >> =E2=80=98=E2=80=98Modify=E2=80=99=E2=80=99 includes the case where the= new value being stored is the > >> same as the previous value. >=20 > C11 also specifies a sequence for assignment (6.5.16.3): >=20 > > 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.