This is the mail archive of the libc-alpha@sourceware.org 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


Daniel Jacobowitz <drow@false.org> writes:

> On Tue, Oct 18, 2005 at 10:51:40AM -0400, James Antill wrote:
>> >  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:
>
> It's also a pretty unpleasant optimization barrier.  Compilers can
> assume that printf does not modify global data - except for printf
> implementations which support user callbacks.

 So fix GCC, a lot of people have custom printf like functions and
would appreciate the same kind of mapping as (printf -> fwrite(),
sprintf -> memcpy() -- which is what I assume you are talking about)
for the functions they use.

 And as a freebie, when you've got it to the point where you can
tell GCC that one function can replace 's' another can replace 'ls',
and another can replace 'jd' ... it should be trivial to say function
X replaces '{myobject}', so you can do...

myfmt("%s is %{myobject}", "foo", &foo);

...without having to lie to GCC.

-- 
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/


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