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

[Alejandro Colomar]

Hi Alexander,

On 2026-03-21T02:38:40+0100, Solar Designer wrote:
> Hi Alejandro,
> 
> Thank you for CC'ing me on this, although I don't have a lot to add.
> Just a little.
> 
> I agree that your proposed aprintf(3) API is better than asprintf(3),
> but I am unsure it's better sufficiently to introduce it now that
> asprintf(3) is finally in POSIX and finally behaves consistently between
> *BSDs and glibc.  Sure such consistency should not be relied upon in
> portable code, because POSIX does not mandate it and because older
> systems exist, which is a problem.  Using a new function name like you
> propose ensures code would not even build on an older system, which is a
> safe solution, but would not be practical for portable code for years.

Sorry that I didn't reply to this earlier.  I don't think it's a big
portability issue.  Projects can have their own implementation for the
transition period, while they need to support old systems.  I've written
this for one project I maintain, and I'm also aware of several projects
that define such an API:

	char *
	vaprintf(const char *restrict fmt, va_list ap)
	{
		char  *p;

		if (vasprintf(&p, fmt, ap) < 0)
			return NULL;

		return p;
	}

	char *
	aprintf(const char *restrict fmt, ...)
	{
		char     *p;
		va_list  ap;

		va_start(ap, fmt);
		p = vaprintf(fmt, ap);
		va_end(ap);

		return p;
	}

In fact, for project using gnulib, they'll already have the API
available in older systems.

> That said, I agree with your reasoning and I have no objections.

[...]


Have a lovely day!
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/20260517/a5b9c609/attachment.sig>