[BusyBox] [patch] New applet, "count".

[Manuel Novoa III]

Hello Rob,

On Sat, Oct 04, 2003 at 01:07:02AM -0500, Rob Landley wrote:
> On Friday 03 October 2003 20:29, Manuel Novoa III wrote:
> 
> I'm under the vague impression that there needs to be some kind of global 
> declared at the top of the file with the applet's name in it.  I think I saw 
> it in one of the other files...

Possibly the string is shared and it was global to save data
duplication?  Can't say without seeing it though.

> As for long long, I'm not against doing it but I am against additional config 
> options that serve very little purpose.  How about instead of making it a new 
> option, make it part of long file support, which we already have a config 
> option for. :)

It really is a seperate issue.  The large file support options mainly
controls the size of offset_t to use, as well as redirecting various
functions to their *64() analogues.  You might want to be able to
count higher than ULONG_MAX and yet not want large file support.

> > You can replace the two fprintf calls with one fprintf and one fputc,
> > as illustrated below.
> 
> At the expense of no message for 0 bytes written.  But that's not the end of 
> the world.
> 
> Actually, if the increment were inside the curly brackets but the fprintf were 
> outside, the behavior would be correct for 0 bytes because of the do { } 

Uh... why do you think it wouldn't output anything for 0 bytes
transfered?  It would still satisfy the if condition.  rv would
be 0 (>=0) and bb_full_write would return 0.

Unless you are talking about the case of a read/write error on the
first iteration.  Yes, in that case it would not output a byte count
prior to the error message.  I suppose some people might want it to.

> > Consider the rewritten version below.  It is slightly larger, but does
> > proper error checking and has better busybox integration.
> 
> It's a distinct improvement over mine.  Only two suggestions: llu based on 
> CONFIG_LFS, and moving the curly brackets so "0 bytes" is printed for a 
> stream that had no data pass through it.
> 
> (Okay, and I couldn't resist a very minor cleanup to the return logic, which 

Well, probably better to do the fputc() unconditionally.

> probably broke something because I have no caffiene in front of me at the 

No.  Actually, it seems to save 2 bytes in one configuration.

> I would like to point out that "safe_read" does not have a bb_ appended to the 
> front of it.  I fixed that as well (well, ok, I made it compile.  I take no 
> position about whether or not it SHOULD have a bb_ on the front of it, but 
> that's a much bigger patch...)

Indeed.  My error.  I tested in isolation and just whipped up some
defines.

Manuel