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
next prev parent 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).