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

["ghazi at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From ghazi at gcc dot gnu dot org  2005-06-10 12:55 -------
(In reply to comment #25)
> Subject: Re:  GCC should combine adjacent stdio
>  calls
> On Fri, 10 Jun 2005, ghazi at gcc dot gnu dot org wrote:
> > Case (b) involves fmemopen, and I assume you refer to a case where you open 
> > memory for writing, printf to the resulting FILE*, and pass a pointer to  
> > the memory area back into printf.  This can only lead to disaster as you 
> > clobber the same memory you are reading from.  Since fmemopen is a gnu  
> > extension, it can do whatever it wants, but I suspect you're entering 
> > unspecified territory here for C programs.
> > 
> We support programs which use functions other than the standard C ones - 
> naturally as the compiler for the GNU system we support extensions in the 
> GNU libraries.  The example I gave used %.5s specifically so that it would 
> only look at bytes with known values (if the programmer knows something 
> about the possible values of the integer written) and not at bytes being 
> modified by the printf.

My point about gnu extensions, is that for corner cases like this we don't have 
a reliable standards document to make judgements from.  We're essentially 
relying on the code as a reference implementation.  So "it can do whatever it 
wants."

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.


-- 


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