home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / c / 3309 < prev    next >
Encoding:
Text File  |  1993-01-01  |  2.8 KB  |  56 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!rfg
  3. From: rfg@netcom.com (Ronald F. Guilmette)
  4. Subject: Re: Standard conformance and GCC 2.3.3
  5. Message-ID: <1993Jan1.115804.23071@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <1992Dec30.173634.15487@crd.ge.com> <1992Dec30.203555.3615@netcom.com> <1992Dec31.150047.22321@crd.ge.com>
  8. Date: Fri, 1 Jan 1993 11:58:04 GMT
  9. Lines: 45
  10.  
  11. In article <1992Dec31.150047.22321@crd.ge.com> volpe@ausable.crd.ge.com writes:
  12. +In article <1992Dec30.203555.3615@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
  13. +|> In article <1992Dec30.173634.15487@crd.ge.com> volpe@ausable.crd.ge.com writes:
  14. +|> +These diagnostics are prefectly friendly and very helpful. Since the
  15. +|> +declarations allocate no storage (there's no object being defined), a 
  16. +|> +storage class specifier is useless and superfluous.
  17. +|> 
  18. +|> I disagree violently with the assertion that the issuance of errors for
  19. +|> perfecly "standard conformant" code is "perfectly friendly and very helpful".
  20. +|> Anyone who says such a thing obviously does not port code for a living!
  21. +
  22. +I disagree violently with the assertion that any errors one might make
  23. +would necessarily result in non-standard-conformant code. Just because 
  24. +it's conformant doesn't mean it's intended. Anyone who says such a thing
  25. +obviously never writes original code for a living, or otherwise is a 
  26. +complete programming God who has never made a mistake and never found
  27. +lint to be the least bit useful. 
  28.  
  29. There is a big difference between using an optional tool like lint, and/or
  30. having warnings which you can *ignore* at your option, and getting *hard*
  31. errors from your compiler for perfectly standard conformant code.
  32.  
  33. Lint is good.  Warnings are good.  Hard errors for perfectly standard
  34. conformant code are BAD!  I do not wish to have my compiler give me s**t
  35. when I'm trying to port some perfectly standard conforming code.  Nor do
  36. I think that it should be forcing me to change such code, just to get
  37. it to compile and link.
  38.  
  39. +I would *never* write the above piece of code intentionally, no matter
  40. +how conformant it is, and I would appreciate some kind of warning that
  41. +I had obviously omitted some variable names in those declarations.
  42.  
  43. As I say, warnings are one thing, and hard errors are another.  Please
  44. do not confuse the two.
  45.  
  46. -- 
  47.  
  48. // Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
  49. //
  50. //      "On the one hand I knew that programs could have a compelling
  51. //       and deep logical beauty, on the other hand I was forced to
  52. //       admit that most programs are presented in a way fit for
  53. //       mechanical execution, but even if of any beauty at all,
  54. //       totally unfit for human appreciation."
  55. //                                              -- Edsger W. Dijkstra
  56.