[Toybox] Fwd: toybox - added cmp

[Rob Landley]

On 02/07/2012 05:08 PM, Tim Elliott wrote:
> I'm attaching an implementation of head. The patch also removes a
> comment in toys/nice.c.
> 
> Notes:
>   * The spec states "The application shall ensure that the number
> option-argument is a positive decimal integer." and this doesn't do
> that. GNU coreutils has some kind of special behavior when n < 0

Well we've got "x#<0" now, but ensuring they didn't specify "4.7" is a
separate issue.  Let's see:

  head -n walrus
  head: walrus: invalid number of lines

And the FSF's track record of custom error strings for every possible
condition (make this program bigger, more english to translate to
foreign languages...) continues unabated, I see.

Sigh.  I hacked an error_exit() into atolx() so if it didn't consume its
input it aborts the program.  I note that since I'm under the age of 50,
when _I_ say "hack" in this context I mean some varaint of:

  http://en.wikipedia.org/wiki/Hack_writer

I.E. it is not a term of endearment for the code in question...

>   * I noticed get_line() in lib/lib.c. Should I be using that instead?

Actually in this case toybuf is faster because you're doing 4k reads
instead of single byte reads.  (You're handling the leftover buffer
yourself. :)  And this avoids malloc/free in the loop.

Let's see, cleanup pass:

The DEFINE_GLOBALS() block starts out zeroed, so you don't have to
initialize TT.file_no to that. (Uninitialized global variables are
actually always like that, they go in the "bss" section which is
prezeroed when allocated.  I think it's actually the ELF spec rather
than c99 that guarantees these are prezeroed, but it _is_ guaranteed by
a standard.)

I mentioned adding #<0=10 so let's use that... Use xprintf() (although
xwrite() probably would have caught it anyway), couple
cosmetic/whitespace things...

Minor bug:

    for(i=0; i<len; i++)
        if (toybuf[i] == '\n' && --lines < 1) break;

    xwrite(1, toybuf, i+1);

So if you go through the whole loop above without running out of lines,
i==len and then you write out len+1 bytes, more than the buffer.
(Writing out a null terminator is a subtle sort of bug, but it can
confuse programs using the output.)  Lemme fix that...

Looks good.  Applied.

Thanks,

Rob

 1328791699.0