NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/amiga/programm/18563

Text File | 1993-01-12 | 3.5 KB | 84 lines

Newsgroups: comp.sys.amiga.programmer
Path: sparky!uunet!well!comeau
From: [e-mail] (Greg Comeau)
Subject: Re: Version Strings...
Message-ID: <[e-mail]>
Originator: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail] (Greg Comeau)
Organization: Comeau Computing
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 12 Jan 1993 14:09:35 GMT
Lines: 70

In article <[e-mail]> [e-mail] (John Lee) writes:
>In article <[e-mail]> [e-mail] (Greg Comeau) writes:
>>In article <[e-mail]> [e-mail] (John Lee) writes:
>>>....  By then, it's too late since the
>>>linker can't throw out things in a module.
>>
>>What can't it throw it away?  (I obviously feel it can).
>
>The answer is...it _can_!  *BUT* the linker and the object code
>generators (be it assembler or compiler) must cooperate in a way that
>they current don't.

I have a feeling we went from a generic concept to a specific
product.  You imply that no Amiga linker has this capability.
I have honestly never looked, but that that is so does not dispute
that it is technically possible to do so.

Yes indeed, the info et al generated by the compiler would have to be
detailed enough to enable this to occur.

>Currently, BLink and most traditional linkers operate at the "module"
>level, where (usually) one source file equals one object module.  At
>this level, the linker can detect that a module has no references to
>it, assuming that it's not the startup module, and easily throw it
>out.  (I don't know of any linker that does this, however.)

Again, I don't know about on the Amiga, but I know of other linkers
on other platforms that do this.  And speaking of traditional,
if I remember correctly (and no, I'm not showing my age ;-}),
even the MVT/MVS linkers had this capability.

>It can't
>throw out parts of a module because of internal references (i.e.
>offsets) not mentioned in the symbol table.  It can't removing strings
>from the middle of a module without adjusting those internal
>references.

So it adjusts them.

>But why complicate an already complicated link process?  The whole
>point is to clean up stuff the programmer has left in by accident.  I
>have a better idea... ......If you don't want nonsense to
>clutter your executables, use "lint"-like tools or have the compiler
>warn you about the nonsense.

Both are great things and great even at the points of time where
the diagnostics can be uttered.  However, my past experiences have
led me off where I had to use both 3rd party header files and
3rd party object code.  Either I couldn't lint it, or shouldn't
lint it.  If I care, that only leaves me other alternatives.

>I think SAS/C will warn you about
>non-referenced statics, but not about non-referenced globals
>(externally-visible symbols.)  "lint" will warn you about both.

Only in the presense of source code I can change.
Hopefully I get a shot at complaining about some ill constructions
or artisty shoved at me, but we don't always have that liberty.

>The bottom line?  "lint" is your _friend_.  Everybody should get to know
>their friends.

The bottom line to me is more like use what you can use until you can't.

- Greg
--
         Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
                Producers of Comeau C++ 3.0/3.0.1 With Templates
          Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
        Voice:718-945-0009 / Fax:[phone] / Prodigy: tshp50a