[leafnode-list] getaline() (once more)

[krasel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx (Cornelius Krasel)]

Matthias Andree wrote:

[sorry to snip all the rest, I want to focus on getaline() only here;
 that's why I also changed the subject]

> I did not see what was wrong with my getline/getaline implementation,

IIRC you suspected that your getaline implementation was very slow.
I must confess that I have not benchmarked it. I tried to use GNU
getline() (from the glibc of SuSE 6.3 which identifies itself as
"GNU C Library stable release version 2.1.2") and observed the symptoms
mentioned in the ChangeLog when running the test suite included in
1.9.17ma3.

The reason I changed getaline() again was that I had 2.0b5 exit with
a huge memory allocation (i.e. proper exit code by critrealloc())
when retrieving a certain XOVER record from upstream. It turned out
that the References: in this XOVER record were truncated by the
upstream DNEWS (or possibly on the server before) and contained a
NUL byte. getaline() had some difficulties identifying this (or the
"real") NUL byte and therefore continued to reallocate exponentially
increasing amounts of memory.

Therefore I did two things:

1) I forced getaline() to always start with 256 bytes of RAM. This
   is IMO meaningful because most lines will not have more than 256
   chars in length. Therefore, we conserve memory.
2) I switched back to the 1.9.16 version of getaline(). I found out
   that this version is very similar to the corresponding function
   of the tin newsreader. NNTP traffic is characterized in that a
   line always ends with \r\n (or, if reading from a textfile, with
   \n).
   I tested the 2.0b6 version of getaline() against the getaline()
   test suite of 1.9.17ma3 and found that it failed test 5 (IIRC),
   namely it will not read a single NUL byte from a file. I think
   this case is not relevant to either NNTP traffic or the reading
   of textfiles.

I agree that this version is still not satisfactory in that it cuts
off chars after encountering a NUL byte. In the case mentioned above,
this apparently did no harm (probably because tin could live without
the missing Xref: information) but I don't want to rely on this kind
of luck :-)

--Cornelius.

-- 
/* Cornelius Krasel, U Wuerzburg, Dept. of Pharmacology, Versbacher Str. 9 */
/* D-97078 Wuerzburg, Germany   email: krasel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx */
/* "Science is the game we play with God to find out what His rules are."  */

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list