Re: new snapshot available: coreutils-8.23.237-eff51

[Pádraig Brady]

On 29/06/15 00:47, Jim Meyering wrote:
> On Sun, Jun 28, 2015 at 3:08 PM, Pádraig Brady <address@hidden> wrote:
>> On 28/06/15 21:01, Jim Meyering wrote:
>>> From 8fc96e0a280211e7cdf0da5b685c1ec6b7668f78 Mon Sep 17 00:00:00 2001
>>> From: Jim Meyering <address@hidden>
>>> Date: Sun, 28 Jun 2015 10:17:57 -0700
>>> Subject: [PATCH 1/2] maint: factor.c: touch up preceding change
>>>
>>> * src/factor.c (print_factors_single): Add a "const" attribute.
>>> Make "n_out" a more faithful count of output bytes.
>>> ---
>>>  src/factor.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/factor.c b/src/factor.c
>>> index 60cf898..5b73c90 100644
>>> --- a/src/factor.c
>>> +++ b/src/factor.c
>>> @@ -2364,9 +2364,9 @@ print_factors_single (uintmax_t t1, uintmax_t t0)
>>>        {
>>>          char buf[INT_BUFSIZE_BOUND (uintmax_t)];
>>>          putchar (' ');
>>> -        char *umaxstr = umaxtostr (factors.p[j], buf);
>>> +        char const *umaxstr = umaxtostr (factors.p[j], buf);
>>>          fputs (umaxstr, stdout);
>>> -        n_out += strlen (umaxstr) + 1;
>>> +        n_out += 1 + strlen (umaxstr) + 1;
>>
>> Is the extra 1 really required?
>> The trailing one was there to cater for the putchar().
> 
> In a sense, it's not required... in that it doesn't really make
> a difference if we're off-by-1-byte-per-line when deciding whether
> to flush.
> 
> I thought the trailing "+ 1" was for the fputs-added newline,
> so added the preceding "1 +" for the putchar.

The new tests/misc/factor-parallel.sh in this area was failing
on FreeBSD (derived) systems where PIPE_BUF = 512 is significant.
The attached patch rewrites this code and implements the line buffering
internally to factor, and with that the test passes on all systems.

cheers,
Pádraig.

factor-pipe-buf.patch
Description: Text Data