From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 93AEC3858D37; Sat, 11 Nov 2023 17:37:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 93AEC3858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1699724231; bh=ilaxly+00Okq1bguS6lwAqw2T8Wx5HG0GWEP3cmTc9A=; h=From:To:Subject:Date:From; b=SkNcdO/feoo2524Ob+ck9KjARVEq2Xm3v9gsUXWqyGjC3tNYrA4r/uEKJLlrYcttr Q5VEueN7zB8s+E10wNq+4nNWJhRK1NSuCFVg+BwiBleHRSbyn+H/q2C+gx5G+UuUdr iflVBDmS5a4E0jBpAv+dGdp8cbC3NjVhbuk+EGNc= From: "post+sourceware.org at ralfj dot de" To: glibc-bugs@sourceware.org Subject: [Bug string/31055] New: Request: guarantee that memcpy(x, x, n) is well-defined Date: Sat, 11 Nov 2023 17:37:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new 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: post+sourceware.org at ralfj dot de 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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 Bug ID: 31055 Summary: Request: guarantee that memcpy(x, x, n) is well-defined Product: glibc Version: 2.38 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: string Assignee: unassigned at sourceware dot org Reporter: post+sourceware.org at ralfj dot de Target Milestone: --- The documentation for memcpy states > The behavior of this function is undefined if the two arrays to and from = overlap However, this contract is suboptimal for several large consumers of this AP= I, including GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D32667), clang (https://reviews.llvm.org/D86993), and rustc (https://doc.rust-lang.org/nightly/core/index.html#how-to-use-the-core-libr= ary). All of these compilers assume that when both pointers are equal, memcpy is effectively a NOP. (I am not a compiler backend engineer, so I cannot fully explain why they consider this contract insufficient and are amending it unilaterally. But t= here seems to be a widespread consensus on the compiler side that adding an extra conditional to guard against the case of both pointers being equal has significant cost. Obviously compilers should have tried to work with libc implementations and not just unilaterally assume a different contract than = what is documented; I cannot speak to the history of how we got here, I would ju= st like to improve the situation here and now.) Efforts seem to be underway to change the C standard to make this API contr= act more useful for these compilers (https://reviews.llvm.org/D86993#4585590), = but that is a slow process. So in the meantime it would be great if glibc could guarantee that for the special case where to=3D=3Dfrom, behavior is indeed well-defined. (Given that in particular the flagship compiler of the GNU project itself makes this assumption, I hope this is a reasonable request.) My assumption is that this only requires a change to the documentation, and that the implementation is already well-defined for to=3D=3Dfrom. If, howev= er, the implementation of glibc on some targets is *not* producing well-defined res= ults for to=3D=3Dfrom, then that would also be very interesting to know. --=20 You are receiving this mail because: You are on the CC list for the bug.=