------- Additional Comments From joseph at codesourcery dot com 2005-06-09 19:52 ------- Subject: Re: GCC should combine adjacent stdio calls
On Thu, 9 Jun 2005, dnovillo at redhat dot com wrote: > > Although it may not be valid to manipulate the FILE * directly, it seems > > quite possible that a program might call another <stdio.h> function > > between the printf calls > > > That is fine. Any call between the two builtins blocks the > merging. > > > that function on the particular implementation > > having a macro expansion without a function call. > > > Sorry, you lost me here. Suppose an implementation defines e.g. clearerr as a macro, and the expansion of that macro just clears bits in the stdio structure and doesn't call any functions. Then though the user's source code looks like it contains a function call, after preprocessing it contains manipulation of bits of the FILE structure for stdout instead. > > It is also possible > > that values of arguments to the second built-in printf call may depend on > > the first one having been previously evaluated; for example, given > > > > extern char *s; > > extern int i; > > > > printf("%d", i); > > printf("%.5s", s); > > > > you can't merge the printf calls because the first one could have changed > > what is pointed to by s. > > > How can printing an integer to stdout affect 's'? Unless 's' has > been somehow mapped to stdout's buffer? Is that what you have in > mind? (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982