🚀 go-pugleaf

In the referenced message, Bob Manson <manson@cis.ohio-state.edu> wrote:
}You think 1000 users is a large number in a users program? Suppose I
}decide to start recording all users over a large network in my utmp
}file? (Wouldn't that be nice...how I hate rwho.)

Yes, that might be nice... but if you did that, why would you want to
run "users"?  Three screenfuls of usernames is not particularly
useful.  And as for piping it to another program, there's the small
problem that most "users" programs don't bother to write out any
newlines.  When you have fixed the far more serious problem of most
Unix programs dumping core on such input (not even a "recompile me"
message, how rude), then maybe I'll consider it worthwhile to add the
malloc gunk.

In general, sure, handling arbitrary input is great.  In specific cases
where you can make a confident estimate of the maximum input size, I have
no problem at all with using checked fixed size arrays of ten times
that size.  The benefit is N fewer lines to get wrong, and the cost, if
your estimate is good, is non-existant.

}I'll bet that in a few years, 1000 will be far too small....

What is the precise meaning of "far too small"?  At least one system
where 1000 is too small?  We probably have that already.  But if you
mean that such systems will be common, sure, I'll take that bet.  How
much?

}and I won't be able to
}recompile your program, because let's face it, 99.9% of all Unix
}distributors don't give source.

I give source.  In fact, one reason I like code which prints messages
like "change XYZ and recompile me please" is to discourage bozos from
doing any god damned binary-only distributions of *my* source.
---
Jef

  Jef Poskanzer  jef@well.sf.ca.us  {apple, ucbvax, hplabs}!well!jef
                     "So young, so bad, so what."