Don Lewis wrote:
>
> Would something like %I(off_t) be legal?  Kinda looks like a cast ;-)
> 
> } Unfortunately, if you don't do all the system supplied types, users
> } have to constantly refer to the manual to figure out which types are
> } supported and which aren't; if you resolve to do all the system
> } supplied types, you have to update printf.c (and friends) every time
> } you add a new type, PLUS you encourage users to whine about it not
> } working for THEIR typedefs as well.
> 
> How about a table driven mechanism for the types that printf doesn't
> understand?

  Not that I'm suggesting this is necessarily the way to go, but
there's already at least one library that allows users to add
format specifiers and formatting functions, at run-time, to
the printf() family without undue performance penalties --
libprint-1.1 from comp.sources.unix vol 29 issue 017:

...  bits of README snipped  ...
        * user installable format specifiers 
	      (e.g. %I to print an ip quad given a struct in_addr*)

  This library only allows a single character
for the specifier (plus the usual field width and precision,
etc.) (it does a table lookup in an array of function pointers,
using the character as the index), so the example of
"%foobar_t" that I saw mentioned somewhere wouldn't work with
this library.  

  It seems to me that if we allow multiple-character
specifiers, like "%I128" or "%foobar_t", we should do something
like "%(I128)" or "%(foobar_t)", which makes it clear that the 128
is part of the I, and not literal characters we want to be
printed, since "%(" has no meaning yet (right?).  It could then
be used as such a 'long specifier' delimiter, which avoids the
ambiguity of "%I(off_t)" -- is the (off_t) part a bunch of
character literals, or part of the %I specifier? -- just use
"%(Ioff_t)" or just "%(off_t)", and ... <flash!> ... ambiguity
disappears!

  If we are going to seriously overhaul *printf() (which IMHO may
not be a good idea), we may want to add user-modifiable,
run-time functionality.  Or add a library with a family of
functions userprintf() that allow such modifications, to
prevent confusion.  Perhaps even add a library that uses that
library, and has the extensions for various _t variables already
initialized.  :)

  If I saw printf("%I %Q %Ioff_t", ...) in a program, I'd be
much more confused than if I saw userprintf("%I %Q %Ioff_t",
...), even if adding upper-case specifiers is
POSIX/ANSI/name-your-favorite-standard compliant.

  Just thought I'd add a little more fuel to the fire...  :)

  Brian
-- 
Brian Grayson (bgrayson@ece.utexas.edu)
Graduate Student, Electrical and Computer Engineering
The University of Texas at Austin
Office:  ENS 406       (512) 471-8011
Finger bgrayson@orac.ece.utexas.edu for PGP key.