Re: lynx-dev Dead code removal

[Klaus Weide]

On Mon, 8 Mar 1999, John Bley wrote:

> On Mon, 8 Mar 1999, Kim DeVaughn wrote:
> 
> > Be sure to check on the short names for usage, as well.

I think the "short names" have not been maintained for a long
time.  The were there for platforms where the linker has a low
limit for the length of external names, afaik, but I don't know
if anyone has tried to compile lynx in such an environment in
recent memory - but I would expect it to fail.

> > 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.

The only classes of functions I am aware of that are called through
pointers are

  - HTStream and HTStructured methods.  You'll see them all in struct
    initializers like this:

      PRIVATE CONST HTStreamClass HTFWriter = /* As opposed to print etc */
      {
           "FileWriter",
           HTFWriter_free,
           HTFWriter_abort,
           HTFWriter_put_character,        HTFWriter_put_string,
           HTFWriter_write
      };
  - Protocol load methods (most called HTLoad* or LYLoad*).
    You'll seem them in initializers like

      GLOBALDEF PUBLIC HTProtocol LYLynxCGI = { "lynxcgi", LYLoadCGI, 0 };

  - HTComparer-type functions passed to other functions (for HTBTree_*, at
    least).

For all these, you should notice the references by grepping.
     
> > 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.

The most notable chunks of unused functions of some size may be in some of
the HTAA_* files.

> > 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.

There are "PUBLIC" and "PRIVATE" (static) functions.  I think we are only
talking about PUBLIC functions - gcc gives warnings for unreferenced
static functions.

Most of the remaining unsused PUBLIC functions seem to be from an early
time, probably parts of the libwww and linemode browser interface that
remained unused when lynx went libwww.  I regard their presence as
useful information, they kind of show the ideas behind the modularization.
I would like to see these not removed completely, but commented out.
(I also wouldn't like to see all comments by TimBL etc. removed, they can
teach the archeologists among us something.)

For example I recently revived HText_setStale() [maybe not exactly for
the original purpose] after it had been unused for a long time.  If I had
not seen that old hook, I might have done the same thing with YA flag
in a less logical place.


    Klaus