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,

> That's a good counterargument for the silly mistakes point.  But the cognitive 
> load that programmers need to care about the extra useless argument for no good 
> reason is still a problem of the memset(3) API that bszero(3) simply hasn't.

There is also the cognitive load of having to learn yet another interface. There is
also the overhead of libraries having to implement yet another function. Plus
compilers optimizing it. Maintaining, testing, and documenting it. And so on.

Why would anyone invest all this effort if there isn't a significant gain after all that?
So a new interface must be significantly and measurably better to be worth all this
work. More than 20 years ago people decided that it is not worth it for bzero and
various other functions given they have almost identical equivalents in the C
standard which were already supported on all targets and in most cases better
optimized. One of the most common portability issues was the lack of bcopy and
bzero which lead to hacky and buggy workarounds.

> I'd like to get a rationale for why we should promote strnlen(3) but not 
> bzero(3) that doesn't reduce to "it is standard".  Why would the standard cover 
> on and not the other?

Firstly memchr is not an equivalent of strnlen, it would be something like:

tmp = memchr (p, '\0', n);
len = (tmp == NULL) ? n : tmp - p;

Be honest, would you really prefer writing that over strnlen (p)?

And neither does memchr have the same performance. Searching for zero is typically
faster than searching for any character, so a well optimized strnlen should beat memchr.
Note that doesn't mean it is unreasonable for a generic strnlen to call memchr - one
typically starts optimizing the C standard functions, and generic string functions use
those as primitives if no optimized version is available (yet).

An optimized bzero function wouldn't be faster than memset - while you might need
a check for zero (or duplicate the input byte), that is a small overhead that is hard to
measure on modern hardware. We had a proposal for adding memzero/memclr/
memclear/memset0/memset_zero/... a while back so I measured it and concluded
there is just no benefit. A few decades ago I was programming on an 8MHz in-order
core and every single cycle&byte mattered then, but it's a very different world today!

Cheers,
Wilco