From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11685 Path: news.gmane.org!.POSTED!not-for-mail From: Jens Gustedt Newsgroups: gmane.linux.lib.musl.general Subject: Re: Documentation of memcpy and undefined behavior in memset Date: Thu, 6 Jul 2017 20:52:18 +0200 Organization: inria.fr Message-ID: <20170706205218.6b3b03a2@inria.fr> References: <0F9B48AD-C5B3-44B6-8D82-0985CF8604A0@trust-in-soft.com> <20170706162353.GC1627@brightrain.aerifal.cx> <20170706171101.GD1627@brightrain.aerifal.cx> <20170706172218.GE1627@brightrain.aerifal.cx> <20170706181326.GF1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/77MTlNnoyQPKGaIZfbgfIrv"; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1499367175 17552 195.159.176.226 (6 Jul 2017 18:52:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Jul 2017 18:52:55 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11698-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 06 20:52:46 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 1dTBtK-0003op-1R for gllmg-musl@m.gmane.org; Thu, 06 Jul 2017 20:52:42 +0200 Original-Received: (qmail 17501 invoked by uid 550); 6 Jul 2017 18:52:37 -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 17479 invoked from network); 6 Jul 2017 18:52:36 -0000 X-IronPort-AV: E=Sophos;i="5.40,318,1496095200"; d="scan'208";a="282396462" In-Reply-To: <20170706181326.GF1627@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ Xref: news.gmane.org gmane.linux.lib.musl.general:11685 Archived-At: --Sig_/77MTlNnoyQPKGaIZfbgfIrv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, On Thu, 6 Jul 2017 14:13:26 -0400 Rich Felker wrote: > On Thu, Jul 06, 2017 at 08:38:29PM +0300, Alexander Monakov wrote: > > On Thu, 6 Jul 2017, Rich Felker wrote: > > =20 > > > I'm doubtful of this. Certainly passing a pointer to memcpy with a > > > nonzero n is a guarantee that the pointed-to object is > > > non-volatile. The n=3D0 case is less clear though. =20 > >=20 > > My view is that since in n=3D0 case no memory access inside of memcpy > > takes place, the compiler may not deduce that the pointed-to object > > is ok for speculative reads. =20 >=20 > Indeed, I think that's a valid interpretation, but not the only one; > the problem here is that the specification is ambiguous, and I suspect > nobody wants to fix the ambiguity because they know they're going to > have an argument over what it was intended to mean... No, no, not because of that :) More seriously, if there is existing practice in both ways, the committee would not want to invalidate any of them for just a TC. In consequence, as a user of such functions you'd always have to be conservative. As an implementor, you can basically chose, but this doesn't help much because your users can't rely on that particular behavior. Now when it comes to changes for a new standard, people would certainly be more open-minded. So if anybody thinks they want to make a proposal for C2x, don't hesitate. Jens --=20 :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/77MTlNnoyQPKGaIZfbgfIrv Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCWV6G4wAKCRAP0+hp2tU3 4s4iAJ4xDChIjFaxQgUU+geFtibx8I7K5wCfdpoI6ChXqiUrTcD5hkPOnOPSDeQ= =DBny -----END PGP SIGNATURE----- --Sig_/77MTlNnoyQPKGaIZfbgfIrv--