[Bug tree-optimization/21982] GCC should combine adjacent stdio calls

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From joseph at codesourcery dot com  2005-06-10 13:49 -------
Subject: Re:  GCC should combine adjacent stdio
 calls

On Fri, 10 Jun 2005, ghazi at gcc dot gnu dot org wrote:

> With regards to "%d" followed by "%.5s", I don't see any difference regardless 
> of the buffering mode between two printfs and one in how soon the "%.5s" will 
> see the results of the "%d".  In buffered mode, you probably won't see it 
> regardless unless you happen to hit BUFSIZ just right.  In unbuffered mode, a 
> correctly flushed printf will make the "%d" available.

I don't think there is any requirement for each printf conversion to be a 
separate write() call as long as the whole is written by the time printf 
returns.

Other cases are where the second printf is e.g.

printf("%d", __internals_of_FILE(stdout));

where __internals_of_FILE is a macro expansion returning some internal 
structure changed by the first printf.  feof and ferror are the relevant 
standard functions; they may only return changed values if the file is in 
error status and the second printf redundant (though it isn't clear to me 
that a past error implies a future error and so that the second printf is 
redundant rather than potentially succeeding where the first failed), but 
it would not surprise me if some system implements something like Solaris 
and glibc __fpending as a macro.  In addition, an implementation can 
choose to document parts of its stdio structures and a user can write 
programs based on the implementation documentation.

Not that I really see the benefit of printf merging in any case; without 
statistics showing its effects on real code it seems any size benefit 
could easily be wiped out by inhibiting the sharing of strings used in 
more than one printf because instead they get merged with the adjacent 
different strings.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982