[RFC v1] libio/: Add [v]aprintf()

[Alejandro Colomar]

Hi Adhemerval,

On 2026-03-17T16:26:06-0300, Adhemerval Zanella Netto wrote:
> 
> > 	Projects have come up with APIs for this over time.  GNU and the
> > 	BSDs have it as asprintf(3), but there seems to be consensus
> > 	that this API isn't very well designed; evidence of this is that
> > 	the behavior is slightly different in the various
> > 	implementations, and has changes through history.
> 
> Could you add more details of what is wrong with the current asprintf glibc
> implementation, besides the initial designed limitation ('int' return i
> nstead of ssize_t)?
> 
> We don't have any bugs against asprintf on glibc bugzilla.

Here are three issues of asprintf(3) from the top of my head:

-  Quite often, it's used together with strdup(3) in some conditional.
   Compare:

	if (cond) {
		dup = strdup(s)
		if (dup == NULL)
			goto fail;
	} else {
		if (asprintf(&dup, "...", s, ...) < 0)
			goto fail;
	}
   vs
	if (cond)
		dup = strdup(s);
	else
		dup = aprintf("...", s, ...);
	if (dup == NULL)
		goto fail;

   The code using aprintf(3) is much simpler and more readable.  This
   means it has less chances of having bugs.

   And even in uses not tied to strdup(3), the double-pointer weirdness
   make it unnecessarily complex.

-  Some BSDs guarantee that asprintf(3) sets the pointer to NULL on
   error.  When porting BSD code to GNU, that could result in bugs
   (reding an uninitialized pointer).  I expect this to be unlikely,
   because why would one ever use the pointer after the call failed, but
   not impossible.

-  aprintf(3), by returning the newly allocated pointer, allows using
   [[gnu::malloc(free)]], which would improve static analysis, being
   able to detect leaks, double-free's, and other related bugs.

> On 17/03/26 15:59, Alejandro Colomar wrote:
> > Signed-off-by: Alejandro Colomar <alx@kernel.org>
> > ---
> > 
> > Hi Paul, Joseph,
> > 
> > Since nobody replied, I guess people are not strongly opposed to it, but
> > they probably want to see a patch before spending time with this.
> > 
> > Thus, I've written a patch (or a draft of a patch).
> > 
> > This is the first time I add a function to glibc, and I find it quite
> > difficult, so I'll need some help.  I've added the most obvious pieces:
> > the prototypes and the implementation.  However, this doesn't work at
> > all, so I guess I'm missing stuff.  Would you mind helping me figure out
> > what I'm missing (or what's wrong)?
> > 
> > I tried building this simple test program, but I get linker errors:
> 
> You need to export the symbol by adding a version tag and its name on
> stdio-common/Versions.

Thanks!  I'll try.

> I don't have a strong opinion about this, albeit since gnulib is already
> providing and that committee has shown interest I would way for C standard
> inclusion. 

I don't think we want that.  The committee is bad at choosing names, and
would probably end up choosing a bad name.  Now that we're in time to
pick a name before the committee decides, we should do it, and then tell
the committee about it so that it uses the same name.

In fact, gnulib added it as aprintf(3) precisely for that reason.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260317/0bfa37b6/attachment.sig>