Hi Alex, > 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). Yeah portability is a big issue with these non-standard functions. So even if you aren't considering the large cost of supporting these functions in C libraries, there are also costs in making applications portable, precisely because not all C libraries will support it... > 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. No, the use of non-standard functions is the problem here. bzero was deprecated more than 20 years ago, do you think C libraries will add support and optimize it even if they never supported it before? If it's non-standard, it's never going to happen. If we continue with the mempcpy vs memcpy example of nginx, I presume nginx implements cpymem() similar to this: #if HAVE_MEMPCPY_SUPPORT return mempcpy (p, q, n); #else return memcpy (p, q, n) + n; #endif The define would be set by a special configure check. Now if nginx got say 10% faster from using mempcpy then that would be great and it would be worth the trouble. However there is no difference since compilers typically generate identical code for these cases. So what's the point of mempcpy exactly? By all means, create your own special copy interface function - it's just sugar. But deciding that mempcpy is great and then being forced to do extra work to make it portable for no gain is what I find insane... > Where do you suggest that we put such function? In or out of libc? Well you mentioned that nginx and many other programs already define their own memcpy variants. It's perfectly reasonable to do what you proposed and create a library of inline string functions using standard calls as primitives. If it is a freely usable and portable, any project that likes it could just add it. Cheers, Wilco
