Alejandro Colomar wrote: > > It can return results larger than INT_MAX bytes and thus avoid the > > EOVERFLOW error specified by POSIX [2], unlike the other *printf > > functions. > > Hmmm, I'll incorporate that to the next draft.
Thanks. > BTW, someone mentioned in the C Committee this morning that we could use > the name strdupf() instead of aprintf(), which would be the natural name > if sprintf(3) would have been called strcpyf() (which would have been > quite reasonable, if we had a time-travel machine). The problem is that > it creates inconsistency with s[n]printf(3). But I could accept that > name. I wouldn't accept that name. It should be of the form '*printf', like all other functions of the family. > The list of names I find acceptable are: > > strdupf() > aprintf() > saprintf() > > (in no particular order). What's your opinion of each of these names? strdupf - no, not consistent with '*printf'. I would prefer 'aprintf' actually. Just looked into the major packages that define some 'aprintf' function, and most of them define it with the prototype that you are considering: libxml2.9 char *trio_aprintf (const char *format, ...); (copied into libxslt, wine) wget char *aprintf (const char *fmt, ...) curl char *curl_maprintf(const char *format, ...) (copied into mysql-8.0) zlib char *aprintf(char *fmt, ...) [only an example] (copied into tcl8.6, tcl9.0, boost1.83, boost1.88, binutils-gold) The only different prototype exists in the 'rcs' package: rcs void aprintf (FILE *iop, char const *fmt, ...) (Here the 'a' stands for aborting upon error.) So, this means the migration path for most of the packages that already define some 'aprintf' function would be to not define it if __STDC_VERSION__ indicates C2y. Bruno
