------- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-10 01:20 ------- (In reply to comment #22) > Subject: Re: GCC should combine adjacent stdio calls > On Thu, Jun 09, 2005 at 07:52:42PM -0000, joseph at codesourcery dot com wrote: > > (a) It could be stdio's buffer (via setvbuf). > > > > (b) It could be a glibc memory stream opened with fmemopen (if the user > > assigned to stdout - which glibc allows - or you do this optimization on > > fprintf and not just printf). > > > > (c) It could point to a memory mapping of the file being written. > > > Gah, so we'll need to parse the format string then. Oh, well. > Diego.
While I agree that we need to parse the format string, that's to solve other issues like detecting %n. I'm not convinced the above a-b-c cases Joseph cites are so clear-cut against doing the transformation. To me it seems all three cases are pathological self clobbering actions (read&write to the same place in one action) or rely on when the OS decides to sync the disk. In case (a), you're suggesting that the programmer would allocate a buffer to be used by stdio buffering, pass it to setvbuf, then effectively read and write to this buffer in the same printf statement by printing the contents of the buffer through the very stream it's being used by for buffering. First of all I'd like to know if the standard guarantees the contents of a stdio buffer (not just when it's flushed) at enough level of detail to reliably retrieve results from it in the midst of buffering through it. I checked and found different contents between glibc and solaris2. 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. I'm willing to be convinced otherwise, can you construct a valid code snippet whose behavior is completely specified which works with two separate printf statements but fails when they're combined? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
