Safe coding practices (was Re: Bug in users command)
Sean Eric Fagan
sef at kithrup.COM
Wed Jan 30 20:25:27 AEST 1991
In article <87774 at tut.cis.ohio-state.edu> Bob Manson <manson at cis.ohio-state.edu> writes:
>Hmmm...Lets see what dies on an 13K input line. (Sun SLC+ running
>SunOS 4.1.) Well, tr was happy to convert the spaces into newlines,
>and I don't see much reason to go further, as the output of that could
>be postprocessed as I wished. (Yes, most unix utilities puke badly on
>input lines > 2K.
On kithrup (an SCO SysVr3.2v2 system), tr, grep, and wc all dealt nicely
with a 120k line. (/etc/termcap is useful for such things 8-).) I was
actually quite impressed.
>>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.
>Hasn't stopped HP or AT&T from distributing code with similar limits.
>Won't stop anyone else either.
Just a note here. SCO's version of yacc has some semi-fixed limits. If it
runs out of space for some of the tables, it complains, and says to rerun it
with a different option. The actual message is something like:
Out of <whatever> space. Run with -Sm# option (current
setting 5000).
(That's how I got perl working.) Although that's not the best solution (for
example, it could be argued that yacc should realloc() up the space itself),
it *does* manage what I consider a decent compromise between static space
and run-time limitations.
Anyway, just my two cents...
--
Sean Eric Fagan | "I made the universe, but please don't blame me for it;
sef at kithrup.COM | I had a bellyache at the time."
-----------------+ -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list