Alejandro Colomar <[email protected]> writes: > [CC -= Jon] > > Hi Bruno, > > On 2025-12-15T01:11:03+0100, Alejandro Colomar wrote: > [...] >> > Thanks for your work on these proposals, by the way: >> >> Thank you! :-) >> >> > - 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, 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. > > Then, people started proposing many nonsensical names... > > 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. > I think the breakage from saprintf() would be acceptable (just one hit > in a Debian code search). > > I'll write a proposal, and we'll probably vote it by the end of this > year. > > If gnulib likes this name, you're invited to provide it, which would > hopefully add some points to the committee to follow existing > implementations.
I'm confused, isn't this the same functionality as asprintf which POSIX.1-2024 added? If so, why add it under a new name? Collin
