Re: Proposal for printf functionality enchancement

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Oct 19, 2005 at 01:35:54PM -0400, James Antill wrote:
> 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.

No, that is not what I'm talking about at all, and GCC isn't broken.
Here's an example:

int foo;

static int bar1(void)
{
  return foo;
}

static int bar2(void)
{
  return printf ("%d\n", foo);
}

The compiler can optimize based on the knowledge that bar1 doesn't
modify foo.  It could do the same for bar2, if it knew that there was
no way for printf to do so.  Which there isn't, with the exceptions of
%n (easy to check statically), and custom format characters (basically
impossible to check).

-- 
Daniel Jacobowitz
CodeSourcery, LLC