[Bug libc/6846] Full featured printf hooks

["rsa at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From rsa at us dot ibm dot com  2008-11-25 17:46 -------
(In reply to comment #10)
> We really have to start from the beginning.  The patch makes lots ooof
> assumptions and implies to have the semantics wanted.  I don't agree with either.

The interface and semantics was the part that I was sure you'd have strong
opinions on.  I'll pitch a new design that I have ready and we can go from
there.  What format would you like this to take?  TeX? Glibc Wiki?

> Before any code is written we must nail down the desired semantics.  The
> existing interface is nice because
> - you can have multiple calls to the register functions and unless the
> specifiers clash there is no problem

In order to understand what was required I had to actually write some code.

> - the existing modifiers and specifiers are handled outside the callback
> framework completely for speed.  I.e., if no specifier matches, no code through
> modifiers is needed
> 
> These are both properties I want to preserve.

Absolutely.  There is one minor addition which will impact the existing
framework.  When there is a length modifier registration the internal framework
needs to check to see if there is a length modifier override, exactly like what
is done prior to processing conversion specifiers.

> Therefore it is necessary to define the interface of the new register function
> differently from what you have.  Some of what you propose makes sense:
> 
> - we want to be able to specify flags and length modifiers.  These have clearly
> defined positions in the format specifier
> 
> - we obviously want new format specifiers

> There should be no argument that all characters used for flags, length
> specifiers, and format specifiers must be ASCII characters.  Otherwise the
> formats wouldn't be available across domains.  This means no wchar_t needed and
> only values from ASCII range 32 to 127 (all inclusive) are allowed.

This was my thought as well but the existing printf.h struct printf_info defines
the 'spec' as wchar_t.  I know from experience that you're not a big fan of
changing structure definitions.

> Since the flags, length specifiers, and format specifiers have fixed positions
> and to avoid unnecessary duplication in the code the user of the callbacks has
> to provide, there should be a way to separate out the ways to introduce
> extensions to each of these three types.  I.e., in the register function it
> should be necessary to specify what is introduced (flag, length spec, format
> spec).  The implementation can then have three different tables.  The extra flag

Three different tables will definitely improve performance of the table
traversal/matching over what I have right now.

Are you inclined to introduce a new symbol name for the new registration
function and preserve an older compat interface for the old method?  Or do you
simply want to version the interface and change the parameter list for the new
version?

> and length specification can be carried in a new word in the printf_info
> structure (or its replacement).  Since only user-defined format specifiers can
> handle the new flags etc the implementation can make sure that it calls into one
> (or more, must be a list) of the user-defined format specifier callbacks if any
> of the extra flag bits is set.  If no new flag bit is set and then format
> specifier is known to the implementation, the standard formatting is performed.

I have a few ideas on how to present this that may not require redefining struct
printf_info.

> I don't want to try to define the semantics here.  This is what should be done
> in a design document which should have been the first step.

It was my intention to use code to get your attention/interest.

> Some more specific things about the code (even though not really relevant right
> now):
> 
> - 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.

> - in the fast path (which doesn't handle positional arguments) we should not
> handle the tables either.  That code must remain as fast as before.  It is
> unacceptable that just because of the stupidity of certain people which make
> this complicated extension necessary sane programs gets slowed down.

As I said earlier, the only infringement into the fast-path in my existing
design is to check for the availability of a length modifier override.

> There are certainly many other details I didn't touch here.  We;ll get to that
> once there is a design document.

Yes, for instance, the ability of format specifiers to consume more than one
argument.  Is there actually any sanctioned format specifier (dubious or not)
which defines such behavior?

Also, the existing definition of struct printf_info doesn't account for
multi-byte conversion specifiers.  As far as I can tell there aren't any
proposed C-spec extensions (AVX, VSX, DFP, Altivec) which define them so we're
currently covered.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|0000-00-00 00:00:00         |2008-11-25 17:46:11
               date|                            |


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.