git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Ben Walton <bwalton@artsci.utoronto.ca>,
	Junio C Hamano <gitster@pobox.com>, git <git@vger.kernel.org>,
	Tay Ray Chuan <rctay89@gmail.com>
Subject: Re: [PATCH] Avoid crippled getpass function on Solaris
Date: Mon, 6 Aug 2012 20:23:18 -0400	[thread overview]
Message-ID: <20120807002318.GA17498@sigill.intra.peff.net> (raw)
In-Reply-To: <m2pq73zkmu.fsf@igel.home>

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

  reply	other threads:[~2012-08-07  0:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-05 23:17 [PATCH] Avoid crippled getpass function on Solaris Ben Walton
2012-08-06  1:56 ` Tay Ray Chuan
2012-08-06  2:41   ` Ben Walton
2012-08-06  1:59 ` Junio C Hamano
2012-08-06  2:35   ` Ben Walton
2012-08-06 19:39     ` Jeff King
2012-08-06 19:57       ` Junio C Hamano
2012-08-06 21:31       ` Ben Walton
2012-08-06 21:34         ` Jeff King
2012-08-06 22:09           ` Ben Walton
2012-08-06 22:31             ` Jeff King
2012-08-06 22:39               ` Ben Walton
2012-08-06 22:42                 ` Jeff King
2012-08-06 23:31                   ` Ben Walton
2012-08-07  0:01                     ` Jeff King
2012-08-06 23:05               ` Andreas Schwab
2012-08-07  0:23                 ` Jeff King [this message]
2012-08-07  0:35                   ` Jeff King
2012-08-07  2:18                     ` Tay Ray Chuan
2012-08-07  3:01                     ` Ben Walton
2012-08-07  3:07                     ` [PATCH] Enable HAVE_DEV_TTY for Solaris Ben Walton
2012-08-07  3:43                       ` Junio C Hamano
2012-08-07  4:03                         ` Jeff King
2012-08-07  4:10                           ` Jeff King
2012-08-07 15:31                             ` Ben Walton
2012-08-08 14:13                             ` Erik Faye-Lund
2012-08-08 21:05                               ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120807002318.GA17498@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=bwalton@artsci.utoronto.ca \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=rctay89@gmail.com \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).