This is the mail archive of the
mailing list for the glibc project.
Proposal for printf functionality enchancement
- From: sqweek <sqweek at gmail dot com>
- To: libc-alpha at sources dot redhat dot com
- Date: Tue, 18 Oct 2005 16:44:41 +0800
- Subject: Proposal for printf functionality enchancement
A while ago I was writing a string buffer data type to abstract all
the memory management issues of concatenating strings and the like, so
that I wouldn't have to deal with any fixed length char arrays and the
possibility of buffer overflow. I ended up writing a version of
sprintf (mainly because asprintf wouldn't link in windows using
-mno-cygwin), where I had an idea for extending printf to allow
I'm not sure exactly how different my approach was - I'm looking at
vprintf.c in glibc-2.3.5 right now going 'wtf', but I see a jump-table
in there... essentially, my proposal is rather than store ints in the
jump table, store function pointers. The function's responsibility
would be to append a data type to the string/stream. And with
another function 'printf_add_type(char c, function f)' that modifies
the jump table, user applications could tell printf how to print
custom data types (and possibly customise behaviour of existing format
So, I'm curious whether there exists any glaring issues which make
this impossible or impractical or undesirable. Performance hit? Leaves
the API too exposed? Increased code footprint? Just Not Worth
Bothering since by now everyone has their own way of printing stuff?
Not actually all that extensible (even if you allowed the full ASCII
character set that's a pretty small namespace - if every library
wanted to add a specifier collisions are going to happen pretty fast).
I mean, I'd be surprised if I was the first person to think of this,
so I'm interested to know what you guys think of it.
 Of course there's a complication here regarding flags and format
specifiers - if they overlapped things would be less than pretty...
 I'm not sure of the exact signature but it would need at least a
pointer to the string/stream, pointer to the varadic arguments
(since if you allow for arbitrary types printf can't actually know the
size of the next argument), and the flags.
 I do recall reading of a specification (ANSI?) which stated
something like 'varadic arguments are only valid within a single
function' - I might have answered my own question here, but isn't it
just another variable? Why would it be dangerous to pass a pointer