Re: yesno module consumes too much input

2007-08-18 Thread Jim Meyering
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: new module finpending

2007-08-18 Thread Jim Meyering
Bruno Haible <[EMAIL PROTECTED]> wrote: > 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 wor

Re: yesno module consumes too much input

2007-08-18 Thread Eric Blake
-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

Re: getline.h

2007-08-18 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/18/2007 4:36 PM: > Eric Blake wrote: >> Now that POSIX 200x is standardizing getline and getdelim as part of >> , should we get rid of getline.h and beef up stdio_.h, then >> adjust all the callers (such as yesno.c) to as

Re: lseek on BeOS (2)

2007-08-18 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/18/2007 5:02 PM: > Hi Eric, > > lseek on BeOS has another deficiency: In some cases it can modify the > file offset although the same call fails. POSIX says this should not happen. > But I don't think it's worth working

Re: lseek on BeOS (1)

2007-08-18 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/18/2007 4:59 PM: > Hi Eric, > > The lseek configure-time test fails not only on mingw, but also on BeOS. > Here is a proposed fix. > > 2007-08-18 Bruno Haible <[EMAIL PROTECTED]> > > * lib/lseek.c: Include . >

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

2007-08-18 Thread Bruno Haible
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

2007-08-18 Thread Bruno Haible
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

lseek on BeOS (2)

2007-08-18 Thread Bruno Haible
Hi Eric, lseek on BeOS has another deficiency: In some cases it can modify the file offset although the same call fails. POSIX says this should not happen. But I don't think it's worth working around it in lib/lseek.c. Here is instead a proposed workaround for the unit test: 2007-08-18 Bruno Hai

lseek on BeOS (1)

2007-08-18 Thread Bruno Haible
Hi Eric, The lseek configure-time test fails not only on mingw, but also on BeOS. Here is a proposed fix. 2007-08-18 Bruno Haible <[EMAIL PROTECTED]> * lib/lseek.c: Include . (rpl_lseek): Add workaround code also for Unix platforms. Needed for BeOS. * doc/functi

Re: yesno module consumes too much input

2007-08-18 Thread James Youngman
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: getline.h

2007-08-18 Thread Bruno Haible
Eric Blake wrote: > Now that POSIX 200x is standardizing getline and getdelim as part of > , should we get rid of getline.h and beef up stdio_.h, then > adjust all the callers (such as yesno.c) to assume this? Hmm, can't we wait until the POSIX standard with these changes is official? Arguments pr

Re: yesno module and i18n

2007-08-18 Thread Bruno Haible
> > 2007-08-18 Bruno Haible <[EMAIL PROTECTED]> > > > > * lib/rpmatch.c: Include langinfo.h. > > (N_): New macro. > > (try): Copy the pattern into safe memory before caching it. > > (localized_pattern): New function/macro. > > (rpmatch): Use it. Add translator comments. > >

Re: yesno module consumes too much input

2007-08-18 Thread Eric Blake
-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):

getline.h

2007-08-18 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Now that POSIX 200x is standardizing getline and getdelim as part of , should we get rid of getline.h and beef up stdio_.h, then adjust all the callers (such as yesno.c) to assume this? - -- Don't work too hard, make some time for fun as well! Eric B

Re: yesno module and i18n

2007-08-18 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/18/2007 1:25 PM: > Eric Blake wrote: >>> + translated_pattern = nl_langinfo (nl_index); >> Not reliable. nl_langinfo is entitled to use static storage that can be >> overwritten by later calls to nl_langinfo or by

Re: yesno module and i18n

2007-08-18 Thread Bruno Haible
Eric Blake wrote: > > + translated_pattern = nl_langinfo (nl_index); > > Not reliable. nl_langinfo is entitled to use static storage that can be > overwritten by later calls to nl_langinfo or by subsequent changes to the > locale. You will need to do something like strdup to avoid problems

Re: yesno module consumes too much input

2007-08-18 Thread Eric Blake
-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

2007-08-18 Thread Eric Blake
-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

2007-08-18 Thread Bruno Haible
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

2007-08-18 Thread Bruno Haible
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

2007-08-18 Thread Eric Blake
-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 and i18n

2007-08-18 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/18/2007 9:42 AM: > Eric Blake wrote: >> The yesno module also has a potential POSIX-compliance problem >> on all platforms. Inside rpmatch, the code uses _("^[yY]") to >> get the locale-specific regex to use as the yesex

Re: yesno module and i18n

2007-08-18 Thread Bruno Haible
Eric Blake wrote: > The yesno module also has a potential POSIX-compliance problem > on all platforms. Inside rpmatch, the code uses _("^[yY]") to > get the locale-specific regex to use as the yesexpr. However, > this is not necessarily the same as using nl_langinfo(YESEXPR). Why is this a POSIX

Re: new module 'fstrcmp', generic diff algorithm

2007-08-18 Thread Bruno Haible
Paul Eggert wrote: > I can do > the other part too, if you like, but I figured you'd rather do that. Yes. Just committed this: 2007-08-18 Bruno Haible <[EMAIL PROTECTED]> * modules/fstrcmp: New file, from GNU gettext with modifications. * lib/fstrcmp.h: New file, from GNU gette

Re: new module 'fstrcmp', generic diff algorithm

2007-08-18 Thread Bruno Haible
Paul Eggert wrote: > I installed the following patch into gnulib to accomplish the first part. Thanks. Good to see that we can finally achieve code sharing here, through the use of parametrizable include files. > One piece (a diffseq module) just for diffseq.h, and the other piece > (fstrcmp, say