Hi Bruno, On 2026-03-11T10:36:40+0100, Bruno Haible wrote: > 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.
Hmmm, I'll incorporate that to the next draft.
> > 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
[...]
>
> asprintf 25359
[...]
saprintf 1
>
> str_printf 1060
> alloc_printf 204
> stdc_asprintf 0
>
> Probably 'alloc_printf' and 'stdc_asprintf' are the most appealing ones.
Yeah, those were the most pushed by the committee. But I hate stdc_ as
a prefix so much, so I said no.
> OTOH, this is the way inconsistent API naming arises.
Agree.
> 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.
Agree.
> > 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').
Yeah, the naming of s*printf() functions is not consistent with str*()
functions.
sprintf(3) could have been strcpyf()
snprintf(3) could have been strlcpyf()
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.
> > If gnulib likes this name
>
> I don't like this name particularly, no.
Okay. Do you want me to insist on the name aprintf()?
The list of names I find acceptable are:
strdupf()
aprintf()
saprintf()
(in no particular order). What's your opinion of each of these names?
Would you sort them in order of preference? Any strong aversion to any
of them? Any name you'd like but which I didn't consider?
Have a lovely day!
Alex
>
> 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
>
>
>
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
