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: 3836 bytes --]

Hi Wilco,

On 1/6/23 01:22, Alejandro Colomar wrote:
> 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

For comparison:

strcat: 130785
stpcpy: 8960

They compete for the same functionality.  stpcpy(3) is a lot less used than 
strcat(3).  Not because it's dead, but because it only became standard in 
POSIX.1-2008, while the other has been then since forever, and has been 
"promoted" by ISO and POSIX for a long time.  There's no clear winner on which 
API is better, assuming an optimizing compiler; it depends on what you do with them.

Another one:

strncat: 17091
strlcat: 13989

strlcat(3) is 99% of the time what users should call.  Yet they call it less 
than strncat(3).

Portability seems to be the main driver of those numbers.  Luckily, the 
strlcat(3) numbers are not so bad compared to strncat(3).  However, I still 
wonder if all those uses of strcat(3) are really safe.

Of course, having POSIX try to kill bzero(3), or that it hasn't yet considered 
mempcpy(3), hasn't helped the numbers; but it doesn't mean that programmers 
wouldn't happy with them being blessed by ISO/POSIX.

Cheers,

Alex

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