Jim Meyering wrote:
> Pádraig Brady wrote:
>> http://www.pixelbeat.org/patches/stdbuf.diff
> 
> Looking at the latest, I see this:
> 
> +  else
> +    {
> +      setvbuf_mode = _IOFBF;
> +      /* Note this is done elsewhere in coreutils:
> +         verify (SIZE_MAX <= ULONG_MAX);  */
> 
> Please drop the comment and just use verify here.
> The other test may disappear some day,
> and it costs nothing at run-time.

Of course.  I wrote the comment so I would do this
when I integrated the lib to coreutils, but forgot
to add the FIXME tag and therefore missed it :p

> -------------------
> 
> +      size = strtoul (mode, NULL, 10);
> +      if (size > 0)
> +        buf = malloc (size);    /* will be free by fclose()  */
> +      else
> +        {
> +          fprintf (stderr, _("invalid buffering mode %s for %s"),
> +                   mode, fileno_to_name (fileno (stream)));
> 
> s/mode/quote (mode)/ in case it contains odd bytes.

Well I had quote() originally, but that required linking to
libcoreutils.a which causes the PIC linking errors on 64 bit.

> 
> +          return;
> +        }
> +    }
> +
> +  if (setvbuf (stream, buf, setvbuf_mode, size) != 0)
> 
> The comment above says never to call setvbuf with nonzero size
> and with buf == NULL.  But if malloc fails, that's what happens.

Well the C99 standard says NULL buffers with non zero size are allowed.
GLIBC currently ignores this combination but may support it in future.
FreeBSD currently allocates a buffer internally on the first read/write
operation on the stream.  So I thought it best to not error in this case
as it may actually succeed at a later point.  But I changed it to
fail early as you suggest.

The rest of your comments were hopefully fixed also in the latest version:

http://www.pixelbeat.org/patches/stdbuf.diff

thanks!
Pádraig.


_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Reply via email to