This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposal for printf functionality enchancement

sqweek <> 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:

James Antill --

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]