From: Alejandro Colomar <alx.manpages@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>,
Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: "Martin Liška" <mliska@suse.cz>,
gcc@gcc.gnu.org, "GNU C Library" <libc-alpha@sourceware.org>
Subject: Re: Missing optimization: mempcpy(3) vs memcpy(3)
Date: Mon, 12 Dec 2022 16:56:27 +0100 [thread overview]
Message-ID: <d4d02782-7fb3-19cf-e47b-af01b84b0462@gmail.com> (raw)
In-Reply-To: <Y5dAVQC93vNNkwqO@tucnak>
[-- Attachment #1.1: Type: text/plain, Size: 1725 bytes --]
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/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-12-12 15:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 17:11 Alejandro Colomar
2022-12-12 13:37 ` Martin Liška
2022-12-12 13:44 ` Alejandro Colomar
2022-12-12 13:56 ` Jakub Jelinek
2022-12-12 14:05 ` Alejandro Colomar
2022-12-12 14:48 ` Jonathan Wakely
2022-12-12 14:53 ` Jakub Jelinek
2022-12-12 15:56 ` Alejandro Colomar [this message]
2022-12-12 16:09 ` Jakub Jelinek
2022-12-12 17:15 ` Alejandro Colomar
2022-12-12 17:42 ` Jonathan Wakely
2022-12-12 14:34 Wilco Dijkstra
2022-12-12 14:57 ` Cristian Rodríguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d4d02782-7fb3-19cf-e47b-af01b84b0462@gmail.com \
--to=alx.manpages@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jwakely.gcc@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=mliska@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).