Re: [PATCH] Avoid crippled getpass function on Solaris

On Tue, Aug 07, 2012 at 01:05:45AM +0200, Andreas Schwab wrote:

quoted

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