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, rtime.3, rtnetlink

  bzero(3) is simpler to use, and can avoid silly mistakes that are hard
to spot.  memset(3), while it is necessary in a few very-specific cases,
should be avoided when the memory is to be zeroed.

POSIX and ISO can say otherwise, but it doesn't make any sense to
recommend using memset(3) over bzero(3).

Link: <https://stackoverflow.com/a/17097978/6872717>
Cc: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---
 man2/bind.2              | 2 +-
 man2/mount_setattr.2     | 4 ++--
 man2/openat2.2           | 4 ++--
 man2/perf_event_open.2   | 2 +-
 man2/pidfd_send_signal.2 | 2 +-
 man2/recvmmsg.2          | 2 +-
 man2/seccomp_unotify.2   | 2 +-
 man2/select_tut.2        | 6 +++---
 man2/sendmmsg.2          | 6 +++---
 man2/set_thread_area.2   | 2 +-
 man2/sysctl.2            | 2 +-
 man3/bzero.3             | 4 +---
 man3/getaddrinfo.3       | 4 ++--
 man3/getaddrinfo_a.3     | 2 +-
 man3/getutent.3          | 6 +++---
 man3/mbrtowc.3           | 2 +-
 man3/mbsinit.3           | 2 +-
 man3/rtime.3             | 2 +-
 man3/rtnetlink.3         | 2 +-
 man3/strptime.3          | 2 +-
 man3const/NULL.3const    | 2 +-
 man3type/size_t.3type    | 1 +
 man3type/void.3type      | 1 +
 man7/aio.7               | 2 +-
 man7/netlink.7           | 4 ++--
 man7/unix.7              | 6 +++---
 26 files changed, 38 insertions(+), 38 deletions(-)
  

On 05/01/23 16:37, Alejandro Colomar via Libc-alpha wrote:
> bzero(3) is simpler to use, and can avoid silly mistakes that are hard
> to spot.  memset(3), while it is necessary in a few very-specific cases,
> should be avoided when the memory is to be zeroed.
> 
> POSIX and ISO can say otherwise, but it doesn't make any sense to
> recommend using memset(3) over bzero(3).

bzero is deprecated by POSIX.1-2001, removed by POSIX.1-2008, and on glibc 
implementation now calls memset (previously some architecture added ifunc 
redirection to optimized bzero to avoid the extra function call, it was
removed from all architectures). 

Also, GCC for some time also replaces bzero with memset so there is no gain
in actually call bzero (check glibc commit 9403b71ae97e3f1a91c796ddcbb4e6f044434734).
  

On 2023-01-05 12:48, Adhemerval Zanella Netto via Libc-alpha wrote:
> 
> 
> On 05/01/23 16:37, Alejandro Colomar via Libc-alpha wrote:
>> bzero(3) is simpler to use, and can avoid silly mistakes that are hard
>> to spot.  memset(3), while it is necessary in a few very-specific cases,
>> should be avoided when the memory is to be zeroed.
>>
>> POSIX and ISO can say otherwise, but it doesn't make any sense to
>> recommend using memset(3) over bzero(3).
> 
> bzero is deprecated by POSIX.1-2001, removed by POSIX.1-2008, and on glibc
> implementation now calls memset (previously some architecture added ifunc
> redirection to optimized bzero to avoid the extra function call, it was
> removed from all architectures).
> 
> Also, GCC for some time also replaces bzero with memset so there is no gain
> in actually call bzero (check glibc commit 9403b71ae97e3f1a91c796ddcbb4e6f044434734).

In addition, gcc -Wall warns if you mistakenly pass 0 as memset's 3rd 
arg, which undercuts the argument that bzero avoids silly mistakes.
  

Hi,

>> bzero is deprecated by POSIX.1-2001, removed by POSIX.1-2008, and on glibc
>> implementation now calls memset (previously some architecture added ifunc
>> redirection to optimized bzero to avoid the extra function call, it was
>> removed from all architectures).
>> 
>> Also, GCC for some time also replaces bzero with memset so there is no gain
>> in actually call bzero (check glibc commit 9403b71ae97e3f1a91c796ddcbb4e6f044434734).

Agreed, there is no benefit from using it, and certainly no reason to try to undo
its removal. We should promote standards, not try to subvert them...
A more productive way would be to propose new functions to the C/C++
committees.

> In addition, gcc -Wall warns if you mistakenly pass 0 as memset's 3rd 
> arg, which undercuts the argument that bzero avoids silly mistakes.

Also I think GCC should give a deprecated/obsolete warning (or perhaps error?)
when using bzero, bcmp, bcopy, index, rindex etc so people can start removing
the few remaining uses from ancient code.

Cheers,
Wilco
  

Hi Wilco, Paul, and Adhemerval,

On 1/5/23 22:12, Wilco Dijkstra wrote:
> Hi,
> 
>>> bzero is deprecated by POSIX.1-2001, removed by POSIX.1-2008, and on glibc
>>> implementation now calls memset (previously some architecture added ifunc
>>> redirection to optimized bzero to avoid the extra function call, it was
>>> removed from all architectures).

Sure, POSIX prefers memset(3).  But why?  "Because it is standard" isn't a valid 
reasoning, because POSIX decides what is standard, so it would be circular 
reasoning.

Anyway, the fact that libc doesn't provide it is not a problem for callers: the 
compiler provides it.  And even if the compiler dropped support, one can write 
it with a one liner, which even POSIX once recommended[1]:

     #define bzero(b,len) (memset((b), '\0', (len)), (void) 0)


[1]:  <https://pubs.opengroup.org/onlinepubs/009695399/functions/bzero.html>

>>>
>>> Also, GCC for some time also replaces bzero with memset so there is no gain
>>> in actually call bzero (check glibc commit 9403b71ae97e3f1a91c796ddcbb4e6f044434734).

No gain in generated code; but there's a gain in source code: less cognitive 
load.  Instead of 3 arguments, the order of which is not easy to remember, the 
programmer only needs to care about 2, and they're obvious.

> 
> Agreed, there is no benefit from using it, and certainly no reason to try to undo
> its removal. We should promote standards, not try to subvert them...

I generally promote POSIX; but at the same time I'm not blindly following it, 
and when its decisions don't make sense I will deviate from it.

> A more productive way would be to propose new functions to the C/C++
> committees.

I believe in existing practice as a way of improving the standards.  IMO, it 
doesn't make sense to ask POSIX to add a function, if no-one uses it.

So I think it should be fine to recommend using a well designed API, and use 
that as a way to increase its use, hopefully resulting long-term in a 
reincorporation to POSIX.

I also defend mempcpy(3) over any POSIX or ISO alternatives.  It's simply 
superior to the alternatives, and POSIX should standardize it (and I'd say even 
deprecate memcpy(3), which is a misdesigned API, but I won't go that far for now).

> 
>> In addition, gcc -Wall warns if you mistakenly pass 0 as memset's 3rd
>> arg, which undercuts the argument that bzero avoids silly mistakes.
> 
> Also I think GCC should give a deprecated/obsolete warning (or perhaps error?)
> when using bzero, bcmp, bcopy, index, rindex etc so people can start removing
> the few remaining uses from ancient code.

There are many users of bzero(3) in the wild, and it is a fine API from a 
usability point of view.  Not being promoted by POSIX or ISO is not enough to 
warn about its use.  With that reasoning, we should warn about many GNU 
extensions, and some of them are really fine (so much that many ended up in POSIX).

However, it would be fine to warn about those that are error-prone:

-  bcopy(3)

And also warn about those that have a drop-in replacement in POSIX:

-  bcmp(3)
-  index(3)
-  rindex(3)

I would endorse warning about those.  BTW, I'll rewrite the bcmp(3) page to say 
it's identical to memcmp(3).

> 
> Cheers,
> Wilco

Cheers,

Alex

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

Hi Paul,

On 1/5/23 21:55, Paul Eggert wrote:
> On 2023-01-05 12:48, Adhemerval Zanella Netto via Libc-alpha wrote:
>>
>>
>> On 05/01/23 16:37, Alejandro Colomar via Libc-alpha wrote:
>>> bzero(3) is simpler to use, and can avoid silly mistakes that are hard
>>> to spot.  memset(3), while it is necessary in a few very-specific cases,
>>> should be avoided when the memory is to be zeroed.
>>>
>>> POSIX and ISO can say otherwise, but it doesn't make any sense to
>>> recommend using memset(3) over bzero(3).
>>
>> bzero is deprecated by POSIX.1-2001, removed by POSIX.1-2008, and on glibc
>> implementation now calls memset (previously some architecture added ifunc
>> redirection to optimized bzero to avoid the extra function call, it was
>> removed from all architectures).
>>
>> Also, GCC for some time also replaces bzero with memset so there is no gain
>> in actually call bzero (check glibc commit 
>> 9403b71ae97e3f1a91c796ddcbb4e6f044434734).
> 
> In addition, gcc -Wall warns if you mistakenly pass 0 as memset's 3rd arg, which 
> undercuts the argument that bzero avoids silly mistakes.

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.

If it's about defending a minimal set of functions that serve the basic purposes 
that programmer may need, I'll prepare a counterargument:

Why does POSIX have strnlen(3)?  strnlen(s, n) is just a shorthand for memchr(s, 
'\0', n);

If the similarity wasn't obvious enough, I'll put them together:

strnlen(p, n)  ----  memchr(p, 0, n)
bzero(p, n)    ----  memset(p, 0, n)

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?

Cheers,

Alex

> 

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

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
  

On Thu, Jan 05, 2023 at 05:48:08PM -0300, Adhemerval Zanella Netto via Libc-alpha wrote:
> 
> 
> On 05/01/23 16:37, Alejandro Colomar via Libc-alpha wrote:
> > bzero(3) is simpler to use, and can avoid silly mistakes that are hard
> > to spot.  memset(3), while it is necessary in a few very-specific cases,
> > should be avoided when the memory is to be zeroed.
> > 
> > POSIX and ISO can say otherwise, but it doesn't make any sense to
> > recommend using memset(3) over bzero(3).
> 
> bzero is deprecated by POSIX.1-2001, removed by POSIX.1-2008, and on glibc 
> implementation now calls memset (previously some architecture added ifunc 
> redirection to optimized bzero to avoid the extra function call, it was
> removed from all architectures). 
> 
> Also, GCC for some time also replaces bzero with memset so there is no gain
> in actually call bzero (check glibc commit 9403b71ae97e3f1a91c796ddcbb4e6f044434734).

This whole s/memset/bzero/g patchset seems like a lot of busywork that
doesn't seem to bring any real benefit. I would agree with the rest here
and just drop this. That's just going to add confusion to the manpages.