On Tue, Aug 07, 2012 at 12:03:26AM -0400, Jeff King wrote:

> > So which direction do you guys want to go?  Use the "bidirectional
> > stdio with fseek()" for now, with the expectation that Tay's other
> > series will rewrite it to fd based one?
> 
> I think so. The stdio fix is short and obviously correct, and then Tay
> can either refactor or not as he sees fit for his topic (although if we
> do switch to just a terminal_can_prompt() interface and get rid of the
> term_t ugliness, then there is not even any need to do the rewrite).

And here it is again, this time with a signed-off-by (I fixed my script
after our last discussion, but accidentally copied an old version to the
Solaris VM I just installed. ;) ).

-- >8 --
Subject: [PATCH] terminal: seek when switching between reading and writing

When a stdio stream is opened in update mode (e.g., "w+"),
the C standard forbids switching between reading or writing
without an intervening positioning function. Many
implementations are lenient about this, but Solaris libc
will flush the recently-read contents to the output buffer.
In this instance, that meant writing the non-echoed password
that the user just typed to the terminal.

Fix it by inserting a no-op fseek between the read and
write.

The opposite direction (writing followed by reading) is also
disallowed, but our intervening fflush is an acceptable
positioning function for that alternative.

Signed-off-by: Jeff King <p...@peff.net>
---
 compat/terminal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/compat/terminal.c b/compat/terminal.c
index 6d16c8f..bbb038d 100644
--- a/compat/terminal.c
+++ b/compat/terminal.c
@@ -59,6 +59,7 @@ char *git_terminal_prompt(const char *prompt, int echo)
 
        r = strbuf_getline(&buf, fh, '\n');
        if (!echo) {
+               fseek(fh, SEEK_CUR, 0);
                putc('\n', fh);
                fflush(fh);
        }
--
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