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 B4F6D3858CDB for ; Sat, 25 Nov 2023 17:11:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B4F6D3858CDB 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 B4F6D3858CDB 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=1700932266; cv=none; b=fze+ptxMEPOpX2gW3ZFTMp1xrX5TMZZB0eeoU/l5P9/HNCBAHtArO7W9o3rzCTVWr9j6hDB5mHTz65MgZy2loIdIBhx4JttJdZndLDcKMPiz4z5XnErgsDC3bz5hU8S1zf1vNqy8AsRS6XlCmR2/byeS+GT3nLpPTRtRLK4lEDU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700932266; c=relaxed/simple; bh=cxgHdjx3UjRBhjL2htrZggYrj2pzrYB+/VkBThiqT4g=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=hCtMExt7izIpPODmE80x4prc8wub8XD4OYZ2mnxXIGOWwTpNgDXZvUWDylAYvBI/eT7ZIphQmzw7yTcdSXjq8CUsPVnsVxO/uJANIiSB4HdLYhMxI0EFy8lRLWY694P87Hs2W6mQX8gXPSFtIET6jUrtXO57OyS+vogAySTb5mU= 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 EA5EE3C011BD8; Sat, 25 Nov 2023 09:11:03 -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 e0fVddBHM6qu; Sat, 25 Nov 2023 09:11:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id A083D3C011BEF; Sat, 25 Nov 2023 09:11:03 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu A083D3C011BEF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1700932263; bh=OOxNJxlGD39p4KdHv9Bg1nukDi2DLuxMslhQJwu41Ds=; h=Message-ID:Date:MIME-Version:To:From; b=I99uvlqhd8QjJuIF+axf0c2o+P9iOHwLwTUv/AL21ZaYDHnhZGqE5cgiSOEJh7jIf EVSdPkN8OPqBA1puZenX33DLcTr3e5EDo/18oJ+zD4MvBFriRXKu72bVHN0sdicx65 rD158lTkoSLeUyPGtoqYe/sSDJoqiUPvzmQjP9CzgHNwxqAca/SeXpdgy2nGf/IjMn xVwmioKz6Bk+M4wliXTKk8xSD3Ui9F6TyTHwr4TBqjd6/jfG7sYgQwhb9uSXsLQdud KzQ8EULs3oP0umODlsOEJxKEQXY1xA0H0dTNMDvyjiAhu93F2QqjTPNcqRvM0ODRCm 2fdpUniKR2qKA== 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 pg9pZjp2Lpme; Sat, 25 Nov 2023 09:11:03 -0800 (PST) Received: from [192.168.254.12] (unknown [47.148.192.211]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 8133E3C011BD8; Sat, 25 Nov 2023 09:11:03 -0800 (PST) Message-ID: <9e6eb1ab-9a9d-4b69-ae49-4805ee7cdce8@cs.ucla.edu> Date: Sat, 25 Nov 2023 09:11:03 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Support for memcpy with equal source and destination To: Ralf Jung , Adhemerval Zanella Netto , libc-alpha References: <1e8beece-f865-4309-a28f-6782135e2a8a@linaro.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: 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: On 2023-11-25 00:20, Ralf Jung wrote: > For a memcpy that is implemented in C (rather than assembly), I don't > think it is possible to make this promise (of supporting src==dest) when > there is "restrict" in the signature. Actually it is possible, though it costs a conditional branch compared to the naive approach that generally would work anyway. Here's a sample implementation. When dest == src this function doesn't dereference either pointer, and this satisfies the C standard's rules for 'restrict'. #include void * memcpy (void *restrict dest, void const *restrict src, size_t n) { if (dest != src) { char *d = dest; char const *s = src; for (; n != 0; n--) *d++ = *s++; } return dest; } When n is zero, this implementation also supports NULL dest or src, though that's a separate issue. > when one sees restrict in a signature, it is impossible to tell what the actual constraint is without further documentation: the function needs to say which memory is being accesses through which pointer, and *that* is then where the disjointness comes from. True, and one could document the new guarantee along those lines. Writing the documentation could be a bit tricky, though, as one needs to explain all this stuff clearly without being too prolix.