Eric Blake <[EMAIL PROTECTED]> wrote:
> I could go either way, although I'm leaning toward doing it now;
I agree. Doing it now is fine.
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
Eric Blake wrote:
> freadahead seems like the best of the alternatives to me - it conveys the
> idea of how many bytes have been read ahead, so that you can guarantee
> that many fgetc actions without system calls.
Agreed. I've added this module:
2007-08-19 Bruno Haible <[EMAIL PROTECTED]>
-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?
>
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 8/19/2007 4:14 AM:
> Jim Meyering wrote:
>> I like fpending_in.
>
> The description is: "Determines the number of bytes waiting in the input
> buffer of a stream."
>
> freadahead ?
freadahead seems like the best of the a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 8/19/2007 4:30 AM:
> Paul Eggert wrote:
>> (if I'm understanding things correctly)
>> POSIX says that mv's behavior here depends on nl_langinfo's result and
>> nothing else.
>
> That's not my understanding. http://www.open
Paul Eggert wrote:
> (if I'm understanding things correctly)
> POSIX says that mv's behavior here depends on nl_langinfo's result and
> nothing else.
That's not my understanding. http://www.opengroup.org/susv3/utilities/mv.html
says that
- The processing of user responses uses the LC_MESSAGES lo
Jim Meyering wrote:
> I like fpending_in.
> Not only is it closer to __fpending,
> but it won't make me think of TCP's FIN.
Hmm, I would prefer a name without 'pending'. "pending" refers to a queue
of actions, which is an appropriate analogy for the output buffer but not for
the input buffer.
The
Hello,
Glenn Gillis wrote:
> gtar-1.18 build error on FreeBSD 4.11-RELEASE-p26 using gcc version
> 2.95.4 20020320 [FreeBSD]:
>
> In file included from stdint.h:71,
> from human.h:27,
> from human.c:24:
> inttypes.h:44: #error "This file assumes that 'int' has e
This has not been reported so far (Solaris/amd64 appears to be a rarely used
platform). But I believe that the AMD64 port of Solaris 10 has the same
problem as the SPARC64 port: the internals of the FILE structure are hidden.
This patch generalizes the support for SPARC64 to AMD64.
2007-08-19 Bru
> > 2007-08-18 Bruno Haible <[EMAIL PROTECTED]>
> >
> > * tests/test-lseek.c (main): Disable a test for BeOS.
> > * doc/functions/lseek.texi: Document the BeOS bug.
>
> OK to commit.
Thanks for the review. Committed.
Bruno
Eric Blake wrote:
> you are missing the matching change to lseek.m4 when cross-compiling.
Right. Thanks. I commit it with this additional change.
2007-08-19 Bruno Haible <[EMAIL PROTECTED]>
Eric Blake <[EMAIL PROTECTED]>
* lib/lseek.c: Include .
(rpl_lseek): Add wo
Bruno Haible <[EMAIL PROTECTED]> writes:
> Let me add some trivial modifications (mostly from gettext's copy of
> diffseq.h):
Thanks. Those all work for diff (I just checked).
Bruno Haible <[EMAIL PROTECTED]> writes:
> + /* First, look in the gnulib message catalog. */
> + const char *translated_pattern = _(english_pattern);
> + if (translated_pattern == english_pattern)
> + {
> + /* The gnulib message catalog provides no translation.
> + Try the s
Eric Blake <[EMAIL PROTECTED]> writes:
> I could go either way, although I'm leaning toward doing it now; I'll wait
> for anyone else to speak their mind.
I also lean towards doing it now, since I think it unlikely that
POSIX will change much before becoming official in this area,
and anyway its
16 matches
Mail list logo
