🚀 go-pugleaf

In article <22921@well.sf.ca.us> Jef Poskanzer <jef@well.sf.ca.us> writes:
>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 think the point made here is that there *are* utilities written
with bad a priori limits in their data structures. The most flagrant
examples I can think of are vi and sh. Under certain circumstances,
if you declare too many (== over 30 or so, not really that many!!)
environment variables, vi and sh will dump core on my sun 4/280
running StunOS 4.0.3. It remains to be seen whether Sun addressed this
bug in 4.1, but in the meantime I will agree wholeheartedly with the
opinion that hard limits in code must be avoided.

I've finishing writing a small sh-like shell whose only hard limit
(which I'm thinking of taking out) is the number of commands that can
be entered in a single pipeline. Currently the value is 512; more than
the maximum number of processes allowed on any unix machine I've seen,
so I consider myself safe. But at least I am aware of this as a
shortcoming.


Byron.

--
Byron Rakitzis
byron@archone.tamu.edu