From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 465103857706; Mon, 13 Nov 2023 18:47:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 465103857706 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1699901263; bh=jxDkBqMX4TOvN/2e5IOLVDz1SLrnb68vW3tm29yJiJc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I59CB5MY1rp3Jo3vmB9qEvC/iQSHQTdOB0wjtzyRGzhFYajk4Kg6F39fvYXewWhy7 JQwAEVPeV9ZzWodze3fG4sfHiKuYvsEcsj0es+D6i2DU8OICGj4OWhuozUI0hVKKq8 Dxch4Sph9eJTKtwBN0XsjWNmY4A8RVpa2/f206cs= From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug string/31055] Request: guarantee that memcpy(x, x, n) is well-defined Date: Mon, 13 Nov 2023 18:47:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: string X-Bugzilla-Version: 2.38 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31055 Adhemerval Zanella changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adhemerval.zanella at lina= ro dot o | |rg --- Comment #1 from Adhemerval Zanella --- (In reply to Ralf Jung from comment #0) >=20 > My assumption is that this only requires a change to the documentation, a= nd > that the implementation is already well-defined for to=3D=3Dfrom. If, how= ever, > the implementation of glibc on some targets is *not* producing well-defin= ed > results for to=3D=3Dfrom, then that would also be very interesting to kno= w. >From the draft proposal document [1], it means that memcpy and other string/memory functions might accept NULL/invalid arguments.=20 It would require glibc to remove the __nonnull on various prototypes and ch= eck if the compiler builtin used on fortify would also handle NULL pointers correctly. It would require extending both default and fortify testing, and adding appropriate support if required (on fortify wrappers for instance if there are compiler bugs).=20 I am also not sure if *all* the architecture memcpy implementation handles memcpy(x, x, n) correctly, although I expect it would not be an issue (GCC = is already generating code with this assumption). The PowerPC dcbz trick is not used on powerpc optimization, and cache fill instructions are only used on memset implementations (and for zero fill, so= I don't think this would be an issue). [1] https://docs.google.com/document/d/1guH_HgibKrX7t9JfKGfWX2UCPyZOTLsnRfR6Ule= D1F8/edit --=20 You are receiving this mail because: You are on the CC list for the bug.=