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, (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 (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.

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

Reply via email to