On Mon, 3 Jan 2005, Thorsten Glaser wrote:
Thomas Dickey dixit:
Hm, strlcpy and truncation detection, or so?
something like that (but strlcpy isn't portable).
You could package it, like I do with the portable version of our ksh derivate.
A combined .c file (optimised against the original OpenBSD version) weighs 4255 bytes, including #ifdev HAVE_STRLCPY and #ifdef HAVE_STRLCAT checks as well as HAVE_CONFIG_H.
But I don't see where it would solve a problem. strlcpy assumes you know the length of the output buffer. The places where lynx uses strcpy, we "know" the length. If we don't know (or think we know) the length, it uses StrAllocCopy, etc. And the case where I mentioned, the copying was using a pointer into the buffer, so the relationship wasn't obvious by looking at it.
lynx has its own functions. But with 170,000 lines of source code (50,000 statements), it's possible to overlook the bad usage of fixed buffers among the good ones. Bear in mind that lynx has been audited by several different people (and old bugs are occasionally found - proving that auditing doesn't find all of the bugs).
I sure understand that. (You don't want to see AT&T derived 4.4BSD nroff source either.)
I read some of the nroff source long ago (around 1984), thinking to see how it worked (since the documentation was hmm - lacking). Rather disappointing (few comments). But it was useful for tuning metrics to distinguish bad code from good...
-- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
_______________________________________________ Lynx-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lynx-dev
