Re: [PATCH] bind.2, mount_setattr.2, openat2.2, perf_event_open.2, pidfd_send_signal.2, recvmmsg.2, seccomp_unotify.2, select_tut.2, sendmmsg.2, set_thread_area.2, sysctl.2, bzero.3, getaddrinfo.3, getaddrinfo_a.3, getutent.3, mbrtowc.3, mbsinit.3, rti...

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Hi Alex,

> Many projects redefine those functions themselves, with alternative names, so 
> it's hard to really count how much is the intention of projects to use it, 
> rather than actual use.  Since the standards don't guarantee such functions, 
> projects that care a lot, use a portable name (one that isn't reserved; 
> sometimes they don't even know that there's a GNU extension with that name and 
> use a weird one, such as cpymem() by nginx).

Yeah portability is a big issue with these non-standard functions. So even if you
aren't considering the large cost of supporting these functions in C libraries, there
are also costs in making applications portable, precisely because not all C libraries
will support it...

> The thing is that those APIs are better (imagine that they were all standard, 
> and were all equally known by programmers; which ones would you use?).  Some 
> programmers will want to use the better APIs, independently of libc providing it 
> or not.  In some cases, for high performance programs, good APIs are even more 
> relevant.  Not implementing them in libc, will only mean that projects will roll 
> their own.

No, the use of non-standard functions is the problem here. bzero was deprecated
more than 20 years ago, do you think C libraries will add support and optimize it
even if they never supported it before? If it's non-standard, it's never going to
happen.

If we continue with the mempcpy vs memcpy example of nginx, I presume
nginx implements cpymem() similar to this:

#if HAVE_MEMPCPY_SUPPORT
  return mempcpy (p, q, n);
#else
  return memcpy (p, q, n) + n;
#endif

The define would be set by a special configure check.

Now if nginx got say 10% faster from using mempcpy then that would
be great and it would be worth the trouble. However there is no difference
since compilers typically generate identical code for these cases. So what's
the point of mempcpy exactly?

By all means, create your own special copy interface function - it's just sugar.
But deciding that mempcpy is great and then being forced to do extra work
to make it portable for no gain is what I find insane...

> Where do you suggest that we put such function?  In or out of libc?

Well you mentioned that nginx and many other programs already define their
own memcpy variants. It's perfectly reasonable to do what you proposed and
create a library of inline string functions using standard calls as primitives.
If it is a freely usable and portable, any project that likes it could just add it.

Cheers,
Wilco