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:
OpenPGP_signature
Description: OpenPGP digital signature
