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