gnu@hoptoad.uucp (John Gilmore) (11/05/86)
In article <41985@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) writes: > News 2.11 uses malloc. There is only 1 hard limit in it anymore. (LINES=512) Great. Thanks for fixing this and sorry for the flame. I should have looked in the new code. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa "I can't think of a better way for the War Dept to spend money than to subsidize the education of teenage system hackers by creating the Arpanet."
dhb@rayssd.UUCP (David H. Brierley) (11/07/86)
I have just finished going through the news 2.11 source and found the
following two items in regard to the use of malloc as opposed to using
statically sized buffers/arrays.
1. Setting a maximum of 512 lines on the active file is wrong. I manage
four separate machines here at Raytheon and three of them overflowed the
active file during the recent flood of newgroup messages. I am willing
to take some of the blame for this since I am currently running version
2.10.1 and have been somewhat lax in deleting old newsgroups. I still
think that this limit is wrong! News 2.11 uses dynamic allocation for
most of its one dimensional arrays (character buffers), why not use
dynamic allocation for this extremely important two dimensional array?
(If I get the time I may just whip up a patch to do this.)
2. News 2.11 goes to great lengths to dynamically size the bitmap array
and falls flat on its face in one not-very-unusual set of circumstances.
The size of the bitmap is calculated when the program starts up, based
on the maximum range of each newsgroup. If news is being actively
received when you run readnews/vnews, and SORTACTIVE has not been
defined by the system administrator, you can overflow the bitmap when
you get to the group that had the most articles in it to begin with. I
know that one possible solution to this is to always define SORTACTIVE,
but for company political reasons I can't do that. I have a patch for
this that I developed under 2.10.1 when we first overflowed net.jokes
and as soon as I finish porting it to 2.11 I will send it to Rick and/or
to mod.sources.
While I'm typing I might as well tell everyone about a bug that I have
found in virtterm.c which is the terminal driver module for vnews. The
definition of "struct line" contains a variable which holds the length of
each line of the display. This variable is defined as "char len".
Since several other changes were made to vnews/virtterm.c to support
terminals with displays larger than 24x80, this variable should be
changed to "u_char len" or else it will not support 132 column terminals
on machines where a "char" does not default to "unsigned" (i.e. a VAX).
I found this one way back in 2.10.1 and I thought it had been fixed but
apparently not. Note that vnews will work with wide terminals the way
it is, MOST of the time. It is only when you get a line which actually
goes beyond 127 columns that it blows up. Since most people are kind
enough to format there articles so that they fit on an 80 column screen,
this is not usually a problem. Vnews would usually choke when it tried
to combine the tail end of the return path, the users full name, and the
organization name, especially if the organization name was long.
--
Dave Brierley; Raytheon Co.; Portsmouth RI; (401)-847-8000 x4073
{ allegra, gatech, ihnp4, linus!raybed2 } !rayssd!dhb