This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/6846] Full featured printf hooks
- From: "rsa at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 25 Nov 2008 19:12:36 -0000
- Subject: [Bug libc/6846] Full featured printf hooks
- References: <20080815064110.6846.rsa@us.ibm.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From rsa at us dot ibm dot com 2008-11-25 19:12 -------
(In reply to comment #11)
> (In reply to comment #10)
> > - I don't like that there is a 'free' function needed. There shouldn't be a
> > need for this. All the flags and length modifier functions should do is set
> > some bits etc. And the format specifier callback should just perform its work
> > and be done. It's easy enough to require that registration function tells the
> > implementation something about the size of the parameters it expects.
>
> I originally did exactly what you suggested but then I ran into hard ABI issues.
> I'd hoped that I could have _Decimal128 types peeled off the va_arg list into
> long double 128 types and then just deal with type punning in the callback
function.
>
> There are two reasons this doesn't work. Firstly, on an architecture where long
> double is double we'll lose half the _Decimal128 in the va_arg -> long double ->
> _Decimal128 and the 'next' value will be peeled incorrectly as it will get the
> second double remnant from the previous value.
>
> Secondly, due to bizarre hardware requirements, _Decimal128 types must be passed
> in an even-odd register pair. Peeling a va_arg into a long double won't
> guarantee this because the ABI makes no such requirements on long double 128.
>
Oh I see what you mean. We pass sizeof(_Decimal128) to the registration
function when we register 'e' as a conversion specification for DFP. The printf
internals simply allocate the necessary storage and pass a reference to it to
the user's va_arg_fn callback.
This should definitely remove the need for a free function as long as the
internal code accounts for the fact that an argument (in some specifications)
may consume more than one argument.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6846
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.