home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18536 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  3.2 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!usc!hacgate!SDFSERV!johnl
  2. From: johnl@SDFSERV.hac.com (John Lee)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Version Strings...
  5. Message-ID: <24689@hacgate.SCG.HAC.COM>
  6. Date: 12 Jan 93 01:42:40 GMT
  7. References: <Per_Salmi.0lxs@augs.se> <24661@hacgate.SCG.HAC.COM> <C0KBM1.Kun@well.sf.ca.us>
  8. Sender: news@hacgate.SCG.HAC.COM
  9. Organization: Hughes Aircraft Company, El Segundo, CA
  10. Lines: 61
  11.  
  12. In article <C0KBM1.Kun@well.sf.ca.us> comeau@csanta.attmail.com (Greg Comeau) writes:
  13. >In article <24661@hacgate.SCG.HAC.COM> johnl@SDFSERV.hac.com (John Lee) writes:
  14. >>....  By then, it's too late since the
  15. >>linker can't throw out things in a module.
  16. >
  17. >What can't it throw it away?  (I obviously feel it can).
  18.  
  19. The answer is...it _can_!  *BUT* the linker and the object code
  20. generators (be it assembler or compiler) must cooperate in a way that
  21. they current don't.
  22.  
  23. Currently, BLink and most traditional linkers operate at the "module"
  24. level, where (usually) one source file equals one object module.  At
  25. this level, the linker can detect that a module has no references to
  26. it, assuming that it's not the startup module, and easily throw it
  27. out.  (I don't know of any linker that does this, however.) It can't
  28. throw out parts of a module because of internal references (i.e.
  29. offsets) not mentioned in the symbol table.  It can't removing strings
  30. from the middle of a module without adjusting those internal
  31. references.
  32.  
  33. Moreover, the linker has no idea of what in a module can be left out.
  34. The object module has no information about the smaller units that make
  35. up the module (e.g., strings or arrays.)  But enhance the assembler or
  36. compiler to add this info and to create object modules in the right
  37. way, and the linker can throw away non-referenced objects.
  38.  
  39. But why complicate an already complicated link process?  The whole
  40. point is to clean up stuff the programmer has left in by accident.  I
  41. have a better idea...
  42.  
  43.  
  44. >>Now, if it had been declared:
  45. >>
  46. >>    static UBYTE Version[] = "\0$VER: ProgName 1.0 (7.1.92)";
  47. >>
  48. >>then the compiler might have noticed the lack of references and
  49. >>optimized it away.
  50. >
  51. >Which leads to the earlier question of: but should it.
  52. >I certainly don't want nonsense cluttering up my executables,
  53. >OTOH, there are things like Version (I've seen similar on other systems
  54. >and have even written said type of situations myself), and other things.
  55.  
  56. Good question.  My answer is "No."  If you don't want nonsense to
  57. clutter your executables, use "lint"-like tools or have the compiler
  58. warn you about the nonsense.  I think SAS/C will warn you about
  59. non-referenced statics, but not about non-referenced globals
  60. (externally-visible symbols.)  "lint" will warn you about both.  With
  61. "lint" I can ensure things that belong (like a Version string) belong,
  62. and things that don't are caught.
  63.  
  64. The bottom line?  "lint" is your _friend_.  Everybody should get to know
  65. their friends.
  66.  
  67. -------------------------------------------------------------------------------
  68. The crew faces deadly GURUs!  Next time on AmigaDOS: The Next Generation.
  69.     +--------+            John Lee
  70.     | HUGHES |
  71.     +--------+            Internet: jhlee@hac2arpa.hac.com    
  72. The above opinions are those of the user and not of those of this machine.
  73.