Re: yesno module consumes too much input

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 8/19/2007 12:47 AM: >> The complexity of the yesno-modifying approach seems too high, >> and not limited just to yesno, so I think the per-application >> one-line changes are better. > > Here's the coreutils patch: > > 2007-08-19

closein using freadahead [was: yesno module consumes too much input]

Bruno Haible clisp.org> writes: > Here is such a proposed patch. > > 2007-08-19 Bruno Haible clisp.org> > > * modules/closein (Depends-on): Add freadahead. > * lib/closein.c: Include freadahead.h. > (close_stdin): Skip the fseeko and fflush calls if freadahead (stdin) >

Re: yesno module consumes too much input

Eric Blake wrote: > the current implementation is correct even when stdin is still in the > initial state. However, if you want to optimize it further, such patches > are worth considering. Here is such a proposed patch. 2007-08-19 Bruno Haible <[EMAIL PROTECTED]> * modules/closein (D

Re: yesno module consumes too much input

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 8/19/2007 12:47 AM: >> Jim, you are affected the most - which would you rather see, a relatively >> big patch to yesno/closein that potentially changes API, or a one-line >> patch to each of your five affected programs? >

Re: yesno module consumes too much input

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 8/19/2007 12:47 AM: > The complexity of the yesno-modifying approach seems too high, > and not limited just to yesno, so I think the per-application > one-line changes are better. > Here's the coreutils patch: 2007-08-19

Re: yesno module consumes too much input

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Bruno Haible on 8/18/2007 5:12 PM: >>> >>> results in calling close_stdin first. From there, if close_stdin detects >>> an error, there is the potential for stdout/stderr to be unflushed (and >>> thus output data lost) when close_stdin calls _e

Re: yesno module consumes too much input

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/18/2007 5:12 PM: >> >> results in calling close_stdin first. From there, if close_stdin detects >> an error, there is the potential for stdout/stderr to be unflushed (and >> thus output data lost) when close_stdin calls

new module finpending (was: Re: yesno module consumes too much input)

Eric Blake wrote: > m4 already calls close_stdin always, whether or not it read from stdin, so > the current implementation is correct even when stdin is still in the > initial state. However, if you want to optimize it further, such patches > are worth considering. Here is a primitive function t

Re: yesno module consumes too much input

Eric Blake wrote: > > To make this API more easy to understand, how about this? > > 1) Rename the function 'close_stdin' to 'close_stdin_stdout', > > 2) Add a function 'close_stdin', which closes stdin only. In the > > implementation, arrange that when 'close_stdin' and > > 'close_stdin_s

Re: yesno module consumes too much input

On 8/18/07, Eric Blake <[EMAIL PROTECTED]> wrote: > handler. But that is more invasive, as there are already a number of > programs using atexit(close_stdout). As a user of these functions, if a gnulib change would produce a bug in my code unless I change it, that's likely to cause a problem. T

Re: yesno module consumes too much input

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/18/2007 11:38 AM: > Hi Eric, > >> How about the following patch? >> * lib/closein.c (close_stdin_only): New function. >> (close_stdin): Make closing stdout optional. >> * lib/closein.h (close_stdin_only):

Re: yesno module consumes too much input

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 8/18/2007 10:34 AM: > According to Paul Eggert on 8/17/2007 5:43 PM: >> Eric Blake-1 <[EMAIL PROTECTED]> writes: > >>> is it reasonable to have yesno install an atexit >>> handler on first invocation? If the handler is not

Re: yesno module consumes too much input

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/18/2007 11:53 AM: > Paul Eggert replied to Eric Blake: >>> is it reasonable to have yesno install an atexit >>> handler on first invocation? If the handler is not present, >>> then stdin was never used (at least not by y

Re: yesno module consumes too much input

Paul Eggert replied to Eric Blake: > > is it reasonable to have yesno install an atexit > > handler on first invocation? If the handler is not present, > > then stdin was never used (at least not by yesno). > > Yes, that sounds reasonable to me. Still, I haven't understood what is so special abo

Re: yesno module consumes too much input

Hi Eric, > How about the following patch? > * lib/closein.c (close_stdin_only): New function. > (close_stdin): Make closing stdout optional. > * lib/closein.h (close_stdin_only): Add declaration. This API of closein.h can easily lead to bugs: Say, one piece of code does at

Re: yesno module consumes too much input

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 8/17/2007 5:43 PM: > Eric Blake-1 <[EMAIL PROTECTED]> writes: > >> is it reasonable to have yesno install an atexit >> handler on first invocation? If the handler is not present, >> then stdin was never used (at least not

Re: yesno module consumes too much input

Eric Blake-1 <[EMAIL PROTECTED]> writes: > is it reasonable to have yesno install an atexit > handler on first invocation? If the handler is not present, > then stdin was never used (at least not by yesno). Yes, that sounds reasonable to me. Also, I forgot, you also mentioned something about th

Re: yesno module consumes too much input

y invasive to all the yesno clients (I always like patching root cause, rather than repeating the same patch to all the clients of a buggy API). -- Eric Blake -- View this message in context: http://www.nabble.com/yesno-module-consumes-too-much-input-tf4287835.html#a12208622 Sent from the Gnulib mailing list archive at Nabble.com.

Re: yesno module consumes too much input

Paul Eggert <[EMAIL PROTECTED]> wrote: ... > My kneejerk reaction is that a modified 'closein' is a better way to > go here. That is, the affected programs (and there are not that many > of them) should invoke close_stdin if they have attempted to read > anything from stdin and have not read end-o

Re: yesno module consumes too much input

Eric Blake-1 <[EMAIL PROTECTED]> writes: > 2007-08-17 Eric Blake <[EMAIL PROTECTED]> > > Don't consume too much input when stdin is seekable. > * lib/yesno.c (yesno): Flush seekable stdin. > * modules/yesno (Depends-on): Add fflush. Won't this patch result in lots of unnecessa

Re: yesno module consumes too much input

Eric Blake-1 <[EMAIL PROTECTED]> wrote: > The yesno module has a problem on platforms where exit() > does not implicitly flush seekable input streams (this behavior > of exit() is contrary to POSIX, but glibc behaves this way, > and Ulrich was unwilling to fix the glibc bug [1]). Basically, > beca

Re: yesno module consumes too much input

TRANSLATOR comment before both regex strings in rpmatch.c, to make it obvious that these strings should be consistent with the locale's choice of yesexpr and noexpr, rather than the usual use of _() to designate translated output. -- Eric Blake -- View this message in context: http://www.nabble

yesno module consumes too much input

fflush/fseeko is guaranteed by POSIX and by gnulib + to do what we want, even though it is undefined in C99. */ + if (lseek (STDIN_FILENO, 0, SEEK_CUR) >= 0 && fflush (stdin) == 0) + fseeko (stdin, 0, SEEK_CUR); + return yes; } -- View this message in context: http:/