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

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

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