------- 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
