Missing optimization: mempcpy(3) vs memcpy(3)

[Alejandro Colomar]

Hi Jonathan and Jakub,

On 12/12/22 15:53, Jakub Jelinek wrote:
> On Mon, Dec 12, 2022 at 02:48:35PM +0000, Jonathan Wakely wrote:
>> On Mon, 12 Dec 2022 at 14:09, Alejandro Colomar wrote:
>>> On 12/12/22 14:56, Jakub Jelinek wrote:
>>
>>>> I think that is the case, plus the question if one can use a non-standard
>>>> function to implement a standard function (and if it would be triggered
>>>> by seeing an expected prototype for the non-standard function).
>>>
>>> I guess implementing a standard function by calling a non-standard one is fine.
>>> The implementation is free to do what it pleases, as long as it provides the
>>> expected interface.
>>
>> Even if the program provides a function called mempcpy?

Yes.  Quoting the glibc manual:

"The names of all library types, macros, variables and functions that come from 
the ISO C standard are reserved unconditionally; your program may not redefine 
these names."

And in case someone didn't know that mempcpy(3) was present in glibc, and could 
try to argue that it's unnice of glibc to pretend to reserve a name not 
specified by ISO C, the following applies:

"Names beginning with ‘str’, ‘mem’, or ‘wcs’ followed by a lowercase letter are 
reserved for additional string and array functions. See String and Array Utilities."

<https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html>

ISO C23 will relax that reserve a little bit, but functions defined by libc are 
always reserved, no matter what.

> 
> And even does something completely different...

So, redefining mempcpy(3) is UB.  What happens then, only nasal demons know.

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20221212/6a57aa54/attachment-0001.sig>