[PATCH v7 1/3] Add [v]aprintf(3)

[Alejandro Colomar]

Hi Adhemerval,

On 2026-06-05T15:42:30-0300, Adhemerval Zanella Netto wrote:
[...]
> >> But I do not think this is a hard requirement, nor a blocker for this patch 
> >> (I am not sure if Florian agrees, so I would check with him).
> > 
> > He recently said he wants to block it for this, IIUC.  I'll work on
> > a patch that applies on top of this one, after this one looks good to
> > you.
> 
> Indeed, it seems Florian does want to get this fixed [1].
> 
> [1] https://inbox.sourceware.org/libc-alpha/87h5nmo5cz.fsf@oldenburg.str.redhat.com/

No problem.  Once we finish reviewing this patch, I'll start working on
another patch that applies on top of this one, and send the full patch
set.  However, I want to get this one done first (even if we don't apply
it yet).

[...]
> >> Adds some tests on debug/tst-fortify.c.
> > 
> > Ok.  Does this look good to you?
[...]
> 
> It should suffice.

Thanks!  Amended.

[...]
> >> I think we should add __attr_dealloc_free, that one of the main advertises for
> >> this symbol. Smae for asprintf and the __chk variants.
> > 
> > Agree.  I probably looked at strdup(3) for imitating it, and it seems it
> > is lacking it.  Should we also add it to strdup(3) in string/string.h?
> > 
> > Anyway, here's a diff for aprintf(3):
> > 
> > 	diff --git i/include/stdio.h w/include/stdio.h
[...]
> > 
> 
> Looks ok.

Amended.

> >>> +extern char *__aprintf (const char *__restrict __fmt, ...)
> >>> +     __THROWNL __attribute__ ((__format__ (__printf__, 1, 2)))
> >>> +     __attribute_malloc__;
> >>
> >> I think there is no need to export the __aprintf for a new symbol, we did it
> >> on other symbols (like scanf) we can asm alias depending of the C standard
> >> being used. Since this is a new symbol, we can just use the aprintf.
> > 
> > Can we use aprintf(3) internally within glibc?  Users might have
> > defined aprintf() themselves, since it's non-standard.
> 
> Yes, but in this case there is also no need to export it on the installed headers.
> We can do in on the internal one instead (at include/) and use a libc_hidden_{proto,def}
> to avoid PLTs.

Hmmmm, my head explodes when trying to understand all those declarations
and which ones are exported and not.

I'll try to do what you suggested, but I'll probably get it wrong.  On
Monday I'll get back home (I don't have a copy of the patches in this
computer) and will work on this, and send patches on Monday or Tuesday.
I'll probably need help to fix that, since I'll get it wrong.  :)

> But I would only add it if/when we actually use it.

Makes sense.  That will simplify the initial patch.

[...]
> >>> +    buf = aprintf ("%2000000000d %2000000000d", 1, 2);
> >>
> >> Does it work on ILP32 ABIs (x32 and mips64-n32)?
> > 
> > It would probably ENOMEM instead of EOVERFLOW, I suspect.
> > 
> > I've done
> > 
[...]
> > 
> > (as is done is the asprintf(3) tests.)
> > 
> 
> Ok.

Amended.

[...]
> >> Should we add a LGPL linking-exception clause, as other printf symbols?
> > 
> > I copied this from stdio-common/asprintf.c, IIRC.  I don't see the
> > exception in the other files:
> > 
> > 	$ find stdio-common/ -type f \
> > 		| grep printf \
> > 		| xargs grep -i exception;
> > 	$
> > 
> > The only file within stdio-common/ where I can see the exception is this
> > one:
> > 
> > 	$ find stdio-common/ -type f \
> > 		| grep -v Makefile \
> > 		| xargs grep -i exception;
> > 	stdio-common/isoc99_vsscanf.c:   As a special exception, if you link the code in this file with
> > 	stdio-common/isoc99_vsscanf.c:   the GNU Lesser General Public License.  This exception does not
> > 	stdio-common/isoc99_vsscanf.c:   This exception applies to code released by its copyright holders
> > 	stdio-common/isoc99_vsscanf.c:   in files containing the exception.  */
> > 
> > [...]
> 
> Right, I am not sure why there are added on isoc99_vsscanf.c in first
> place.

Okay; no changes then.

[...]
> > So, should I drop all changes to
> > sysdeps/ieee754/ldbl-opt/nldbl-compat.c?
> 
> I think so.  There is no need for compat symbol, although there is the need
> to handle ABI that defined double == long double (I recall this is done by
> other file in sysdeps/ieee754/ldbl-opt).

Thanks; I'll drop all changes to sysdeps/ieee754/ldbl-opt/nldbl-compat.c
and only those changes.  I hope that's enough.  If not, we'll see in the
next version of the patch set next week.

> > 
> >> New symbols do not get a compat_symbol at an older version (and compat_symbol 
> >> at the current dev version is illegal anyway). Check the __isoc23_* additions, 
> >> which use libc_hidden_def + the normal versioned export.
> > 
> > Would you mind naming a few __isoc23_* names?  I don't know those
> > functions.
> 
> For instance __isoc23_vfscanf.  It is only declared at the installed header if
> there is no REDIRECT support (asm alias).  Since for __asprintf there is no need
> for alias at this moment, there is no need to add such symbol.

Hmmmm.  Again, my head explodes with all this combination of symbols,
but I guess I'll eventually get it.  :)


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/20260605/af444f2e/attachment.sig>