Hi Wilco, On 1/6/23 01:22, Alejandro Colomar wrote:
Hi Wilco, On 1/6/23 01:02, Wilco Dijkstra wrote:Hi Alex,There are many users of bzero(3) in the wild, and it is a fine API from a usability point of view.Since you repeatedly claim lots of use of these functions, I did a quick search on https://codesearch.debian.net/ bzero: 21440 memset: 563054 mempcpy: 4489 memcpy: 692873
For comparison: strcat: 130785 stpcpy: 8960They compete for the same functionality. stpcpy(3) is a lot less used than strcat(3). Not because it's dead, but because it only became standard in POSIX.1-2008, while the other has been then since forever, and has been "promoted" by ISO and POSIX for a long time. There's no clear winner on which API is better, assuming an optimizing compiler; it depends on what you do with them.
Another one: strncat: 17091 strlcat: 13989strlcat(3) is 99% of the time what users should call. Yet they call it less than strncat(3).
Portability seems to be the main driver of those numbers. Luckily, the strlcat(3) numbers are not so bad compared to strncat(3). However, I still wonder if all those uses of strcat(3) are really safe.
Of course, having POSIX try to kill bzero(3), or that it hasn't yet considered mempcpy(3), hasn't helped the numbers; but it doesn't mean that programmers wouldn't happy with them being blessed by ISO/POSIX.
Cheers, Alex
I used "memcpy(" and "memcpy (" and added the results. These overestimate usage due to prototypes and comments, and don't include memcpy and memset calls emitted by compilers so in reality the results are even more skewed.Many projects redefine those functions themselves, with alternative names, so it's hard to really count how much is the intention of projects to use it, rather than actual use. Since the standards don't guarantee such functions, projects that care a lot, use a portable name (one that isn't reserved; sometimes they don't even know that there's a GNU extension with that name and use a weird one, such as cpymem() by nginx).Projects that prefer portability and don't care about using good APIs so much will fall back to the standard APIs, which is most projects, so of course the numbers are not comparable in the wild.The thing is that those APIs are better (imagine that they were all standard, and were all equally known by programmers; which ones would you use?). Some programmers will want to use the better APIs, independently of libc providing it or not. In some cases, for high performance programs, good APIs are even more relevant. Not implementing them in libc, will only mean that projects will roll their own.I'm not saying that's bad either. If we want to simplify libc, and add some extension libraries that are independent of libc, that would provide such functions, that's fine by me. And maybe it's the better thing to do.So, whether you like it or not, a relevant number of programs (although, as you proved, a small one compared to the entire universe of programs) will keep using an API that asks for a pointer and a size and zeroes it. We can call it bzero(3), or memzero(3), or ext_memzero(3) (ext_ being a prefix for a library providing useful extensions to libc), but the function will be there.Where do you suggest that we put such function? In or out of libc?There may be other repositories which can be easily searched, but these results are clear enough to conclude these functions are dead.I'd say dead is too much. Cheers, AlexCheers, Wilco
-- <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
