[Bug libc/6846] Full featured printf hooks

["drepper at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From drepper at redhat dot com  2008-11-25 07:39 -------
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.

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

- 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.

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.

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
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 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.

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.

- 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.

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

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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.