From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) by sourceware.org (Postfix) with ESMTPS id 800C73858CD1 for ; Sat, 25 Nov 2023 07:48:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 800C73858CD1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 800C73858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=131.179.128.66 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700898536; cv=none; b=DNjNKNdDFcJz4xKZikTio21ATPW1IljGyYQWT0VPHC3MhRf+GXmPJ7rr4S8n+OhWjLZ2e4tdFdbDgTgKLqAheKevY7pFSlfr2CNGaXtcsnNozIRVucEBBzwQjEKXFh4fnc+fOHC5Oj+V4bDjHHvsor2S77DQLwNgUWn31/hdJTE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700898536; c=relaxed/simple; bh=H/XjdLRnwwM4CBPBVF+K8qIusngG+Kq1DWpsLABhEKs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=HXIWSVllf39qwDGj60QPOZOXQZEu9QdbplRR/FlrL7eGFGHumf00gaTJ07ODUBLVNh14EzysrQffn1BG5pBdMAoQrhoRQNk+hS/+VkiyAflLlrNfXiWfOFZwZWWlkJqKkUormnFmn0l3RwsKRMmeAQk83nrbnjJtMHSrnTamxlw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 570483C011BEF; Fri, 24 Nov 2023 23:48:54 -0800 (PST) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6IvktyjgNatd; Fri, 24 Nov 2023 23:48:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 0FF7F3C011BF0; Fri, 24 Nov 2023 23:48:54 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 0FF7F3C011BF0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1700898534; bh=3/a0G7OXlCbUMtJa8ZNneun3ycON/9lVggbtriTCbxU=; h=Message-ID:Date:MIME-Version:To:From; b=HWI7HamPqQVafcjJAigkHwsTqhBlribRamwg/ApDRteQ+IgTBCMQsKj8NXEitKoD2 2N60eT7o79Qqs913/43M9OvUZaMVEPKYxeYxTmbwjt0mBO8U65kLmDHHBcFywalsua E1ZjG11I7xiycoUg0YyyYcANSmPJoF0W5oS5aTLd/KNsplNDxOaHxr7uXe/iJAxO6I DomAGDETNottxvWG/NEQUZaAzqXKQsTRm4od3ErZ8Mz2tG66BNuFO4kMGLb0yYNXqS YV9242yifHW+ZC+fg1P4b6g93WK28iE6d0uHiuCfko73cuRq96FlUoFiNc81/LkTgz cKp/LKiT0brVQ== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hpxbvKd2Dk4d; Fri, 24 Nov 2023 23:48:53 -0800 (PST) Received: from [192.168.254.12] (unknown [47.148.192.211]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id EADF53C011BEF; Fri, 24 Nov 2023 23:48:53 -0800 (PST) Message-ID: Date: Fri, 24 Nov 2023 23:48:53 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Support for memcpy with equal source and destination Content-Language: en-US To: Adhemerval Zanella Netto , libc-alpha Cc: post+sourceware.org@ralfj.de References: <1e8beece-f865-4309-a28f-6782135e2a8a@linaro.org> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <1e8beece-f865-4309-a28f-6782135e2a8a@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: I see several areas of possible confusion, so if we make this change to the glibc documentation, the new documentation should make the following clear: * This is a GNU extension, and other C libraries might not guarantee this (not surprising). Also, other C compilers might not guarantee this even when used with glibc (somewhat more surprising). * GCC and other compilers might warn about memcpy (X, X, SIZE) even if it is supported. * This an exception to the usual rule about "restrict", since the prototype says "restrict" but it's OK if the two pointers are the same (so "restrict" now means that they cannot overlap other than being equal, just for this particular function). * The pointers must point to SIZE bytes even when SOURCE == DESTINATION. For example, memcpy (&errno, &errno, SIZE_MAX) is not valid. * If SIZE is nonzero, the destination must be writable even when SOURCE == DESTINATION. * mempcpy, strcpy, and stpcpy are like memcpy in the above respects. (Are there other functions for which we want to make similar guarantees?) The issue with null-or-invalid pointers and size zero is independent of this, as far as I can see, so it can be treated separately.