This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Proposal for printf functionality enchancement
- From: James Antill <nevyn-glibc-alpha at and dot org>
- To: sqweek <sqweek at gmail dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Tue, 18 Oct 2005 10:51:40 -0400
- Subject: Re: Proposal for printf functionality enchancement
- References: <140e7ec30510180144n6017780cq@mail.gmail.com>
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