On Tue, Aug 07, 2012 at 01:05:45AM +0200, Andreas Schwab wrote:
> > The stdio behavior on Solaris is weird. If I run this sample program:
> >
> > #include <stdio.h>
> > int main(void)
> > {
> > FILE *fh = fopen("/dev/tty", "w+");
> > char buf[32] = {0};
> > fgets(buf, sizeof(buf), fh);
> > fprintf(fh, "got %s\n", buf);
> > return 0;
> > }
> >
> > on Linux, I get:
> >
> > $ ./a.out
> > foo <-- me typing
> > got foo <-- program output
> >
> > On Solaris, I get:
> >
> > $ ./a.out
> > foo <-- me typing
> > foo <-- ???
> > got foo <-- program output
>
> That's not a bug, you need to flush or seek when you want to switch
> between read to write.
Thanks. Inserting an fflush() before the fprintf does fix it, but I
think that a flush is disallowed by the standard in this case. From C99,
7.19.5.2 (fflush):
If stream points to an output stream or an update stream in which the
most recent operation was not input, the fflush function causes any
unwritten data for that stream to be delivered to the host environment
to be written to the file; otherwise, the behavior is undefined.
And later, from 7.19.5.3 (fopen):
When a file is opened with update mode ('+' as the second or third
character in the above list of mode argument values), both input and
output may be performed on the associated stream. However, output
shall not be directly followed by input without an intervening call to
the fflush function or to a file positioning function (fseek, fsetpos,
or rewind), and input shall not be directly followed by output without
an intervening call to a file positioning function, unless the input
operation encounters end-of-file.
I don't know if any implementation actually cares in practice, of
course, but probably the sane thing would be to call
"fseek(fh, SEEK_CUR, 0)" before the fprintf.
This is all moot if we end up ripping stdio out of this code for other
reasons, but it does give us another option for a fix.
Thanks for the pointer.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
