Hi Alejandro, > > > - n3750, alx-0007r6 - add a malloc(3)-based sprintf(3) variant > > > (similar to gnulib's xasprintf() and xvasprintf() functions), > > > > I expect we'll vote this one in March, or maybe July. I think it might > > be accepted, but I'm not sure. > > I have news about this. The committee wants the API
Interesting. And this is despite n3750 [1] fails to mention an benefit of this API: It can return results larger than INT_MAX bytes and thus avoid the EOVERFLOW error specified by POSIX [2], unlike the other *printf functions. > but there's no agreement on the name. > > People have complained that aprintf() is too used in the wild, so it > would break a lot of existing code. Indeed, a code search in Debian sources [3] shows a number of existing uses of this identifier. > Then, people started proposing many nonsensical names... If "breaking the least possible amount of code" is one of the main criteria, here are the existing usage counts: aprintf 924 bprintf 2199 cprintf 2019 dprintf 33350 eprintf 17792 gprintf 2274 hprintf 455 iprintf 2008 jprintf 5 kprintf 1381 lprintf 12275 mprintf 21860 nprintf 878 oprintf 2453 pprintf 4606 qprintf 823 rprintf 1942 tprintf 10361 uprintf 561 vprintf 9777 wprintf 3360 xprintf 7392 yprintf 20 zprintf 431 asprintf 25359 bsprintf 356 csprintf 43 dsprintf 95 esprintf 12 fsprintf 0 gsprintf 54 hsprintf 6 isprintf 0 jsprintf 32 ksprintf 2455 lsprintf 106 msprintf 8840 nsprintf 103 osprintf 1758 psprintf 691 qsprintf 0 rsprintf 283 ssprintf 944 tsprintf 345 usprintf 755 vsprintf 11316 wsprintf 987 xsprintf 717 ysprintf 0 zsprintf 0 str_printf 1060 alloc_printf 204 stdc_asprintf 0 Probably 'alloc_printf' and 'stdc_asprintf' are the most appealing ones. OTOH, this is the way inconsistent API naming arises. We discussed strpbrk vs. strspn, strcspn a few weeks ago. A instruction "let's choose an identifier that is rarely used" *will* lead to inconsistent API naming. > I think we have some alternatives. To be fair, I didn't fully like the > name aprintf(), and am now more inclined to call it saprintf(). That > is still used in the wild, but significantly less than aprintf(). Also, > the 's' in the name marks it as being from the s*printf() sub-family. But it's still inconsistent naming: The naming 'sa*' is not used so far (i.e. 'strdup' is not call 'sadup'). > If gnulib likes this name I don't like this name particularly, no. Bruno [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3750.txt [2] https://pubs.opengroup.org/onlinepubs/9799919799/functions/fprintf.html [3] https://codesearch.debian.net/search?q=%5Cbaprintf%5Cb&literal=0
