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

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-06-10 02:00 -------
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.
> 
> Case (c) with mmap again looks like you're reading and writing to the same 
> place, but the results depend on how buffering and disk syncing interact.  
> Again, what guarantees from the C standards do we have here on what the results 
> should look like?  Since IIRC mmap isn't part of C, there are no guarantees.

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.

POSIX defines how streams and file descriptors for the same file can be 
used together and for an unbuffered stream it appears to me that the 
results from writing to it with stdio (within parts of the file that 
already existed; not after its end) should be immediately available in the 
mapped region.



-- 


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