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...

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2629 bytes --]

Hi Wilco,

On 1/6/23 01:02, Wilco Dijkstra wrote:
> Hi Alex,
> 
>> There are many users of bzero(3) in the wild, and it is a fine API from a
>> usability point of view.
> 
> Since you repeatedly claim lots of use of these functions, I did a quick search
> on https://codesearch.debian.net/
> 
> bzero: 21440
> memset: 563054
> 
> mempcpy: 4489
> memcpy: 692873
> 
> I used "memcpy(" and "memcpy (" and added the results. These overestimate
> usage due to prototypes and comments, and don't include memcpy and memset
> calls emitted by compilers so in reality the results are even more skewed.

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).

Projects that prefer portability and don't care about using good APIs so much 
will fall back to the standard APIs, which is most projects, so of course the 
numbers are not comparable in the wild.

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.

I'm not saying that's bad either.  If we want to simplify libc, and add some 
extension libraries that are independent of libc, that would provide such 
functions, that's fine by me.  And maybe it's the better thing to do.

So, whether you like it or not, a relevant number of programs (although, as you 
proved, a small one compared to the entire universe of programs) will keep using 
an API that asks for a pointer and a size and zeroes it.  We can call it 
bzero(3), or memzero(3), or ext_memzero(3) (ext_ being a prefix for a library 
providing useful extensions to libc), but the function will be there.

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

> 
> There may be other repositories which can be easily searched, but these results
> are clear enough to conclude these functions are dead.
I'd say dead is too much.

Cheers,

Alex

> 
> Cheers,
> Wilco

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]