Re: lynx-dev Dead code removal

[John Bley]

On Mon, 8 Mar 1999, Kim DeVaughn wrote:

> | A grep HText_dump `find .` in the top-level dir yields (space truncated):
> | src/GridText.c:PUBLIC void HText_dump ARGS1(
> | WWW/Library/Implementation/HText.h:#define HText_dump HTHTDump
> | WWW/Library/Implementation/HText.h:extern void HText_dump PARAMS((HText*me))
> |
> | I.e., the definition, a name-shortening #define, and a declaration of its
> | existence.  No call.  This example is typical of the rest.  I'll try to
> | track down the complete list sometime soon.  Perhaps Tuesday.
> 
> Be sure to check on the short names for usage, as well.

You're thinking that the #define is backwards, but yes, there are no uses 
of the short names anywhere.  I already checked that path.

> Also, as Tom pointed out, some fn()'s are called in obscure and circuitous
> ways.  I dunno if lynx ever calls fn()'s through pointers, but that is one
> other thing to lookout for.

Yes, several times a macro such as
#define foobar(x)  HTDoSomethingNotCalledFoobar(x)
is done, among other very weird things.  If they're called through 
pointers, I'd see the pointer being assigned, unless somebody is sick 
enough to guess at the offset of the method in the binary before it's 
compiled.

> In short ... caveat emptor.
With dead code tracing, always.

> Also, how much in the way of object size would removing these potentially
> useful fn()'s save, if in fact they really are unreferenced?
For a dozen mostly empty methods, probably not too much... few hundred 
bytes at most.

> For the sake
> of "completeness" (by some metric), it may be better to leave them in.
Which is kinda why I was asking about their history.  If they have a 
chance of being used/implemented sometime soon, yeah, sure, leave them in 
or comment them out in some way.

But otherwise, it just means that they sit there forever until somebody 
asks the question again.  See "Lava Flow" in the book "Antipatterns."

-- 
John Bley - address@hidden
Duke '99 - English/Computer Science
  Since English is a mess, it maps well onto the problem space,
  which is also a mess, which we call reality.     - Larry Wall