Re: Proposal for printf functionality enchancement

[James Antill <nevyn-glibc-alpha at and dot org>]

sqweek <sqweek@gmail.com> writes:

>  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
> user-defined types.
>  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[1]. The function's responsibility
> would be to append a data type to the string/stream[2]. 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
> specifiers).

 You mean like register_printf_function() ?

>  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

 Static format checkers, like GCC, see:

 http://www.and.org/vstr/#cust-fmt

-- 
James Antill -- james@and.org
http://www.and.org/and-httpd