From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11687 Path: news.gmane.org!.POSTED!not-for-mail From: Leah Neukirchen Newsgroups: gmane.linux.lib.musl.general Subject: Re: Documentation of memcpy and undefined behavior in memset Date: Thu, 06 Jul 2017 21:10:31 +0200 Message-ID: <8760f5s7o8.fsf@gmail.com> References: <0F9B48AD-C5B3-44B6-8D82-0985CF8604A0@trust-in-soft.com> <20170706162353.GC1627@brightrain.aerifal.cx> <98d2e82c-1930-5dc2-2afa-bf6f4c9a8a50@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 1499368251 19369 195.159.176.226 (6 Jul 2017 19:10:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Jul 2017 19:10:51 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cc: musl@lists.openwall.com To: Bartosz Brachaczek Original-X-From: musl-return-11700-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 06 21:10:47 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 1dTCAj-0004ZZ-64 for gllmg-musl@m.gmane.org; Thu, 06 Jul 2017 21:10:41 +0200 Original-Received: (qmail 1402 invoked by uid 550); 6 Jul 2017 19:10: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 1371 invoked from network); 6 Jul 2017 19:10:43 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=wrnKOwLGxrh97S/cIQ+o9wLQGU4RTB4zJDIXUoAKVvo=; b=WC6F0qKuP76ZkmlUjqzSxha1owDh3f8WfXRBrcKHtODLPY+7SslhlbBvUI2l4LunVD zfgag/XoqCoasMjCZH8KE5kYCCPsbwDafkin3u0++H7j/evzIYjV4IihJFa55EHqfksg nkYy1S/APOKdeu8DmBXK7zAR9ri3ouD6Ut7kuSyjq204jz4OwzFUOmnEN6q1VcX+ybfU b77fKQRbfJPZD9HCh4nk1ZM4lauMdFOf/F4RUdrNUqFI2Mq0c5Ka2fCnQGXyFI1tK4eQ /XB8dmuKi1JG7ar8Dn9vaDL4FeOwbCmyhJLoh0Zu4Qb00RM3Db2gIlQIBI9Ar/udxyDC d1SA== X-Gm-Message-State: AKS2vOxwjPvYyiEgRg/WlgxwYzpdu0X0zK3/iV8C8fcM7cMmn81R7tq2 tj2uin2kQ8ZAaQ== X-Received: by 10.223.144.39 with SMTP id h36mr48209511wrh.114.1499368232369; Thu, 06 Jul 2017 12:10:32 -0700 (PDT) In-Reply-To: <98d2e82c-1930-5dc2-2afa-bf6f4c9a8a50@gmail.com> (Bartosz Brachaczek's message of "Thu, 6 Jul 2017 21:05:12 +0200") Xref: news.gmane.org gmane.linux.lib.musl.general:11687 Archived-At: Bartosz Brachaczek 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: > >> =E2=80=98=E2=80=98Modify=E2=80=99=E2=80=99 includes the case where the n= ew 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. --=20 Leah Neukirchen http://leah.zone