🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #2998

Re: Standard conformance and GCC 2.3.3

#2998
From: Ronald F. Guilmette
Date: Fri, 01 Jan 1993 11:58
45 lines
2929 bytes
In article <1992Dec31.150047.22321@crd.ge.com> volpe@ausable.crd.ge.com writes:
+In article <1992Dec30.203555.3615@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
+|> In article <1992Dec30.173634.15487@crd.ge.com> volpe@ausable.crd.ge.com writes:
+|> +These diagnostics are prefectly friendly and very helpful. Since the
+|> +declarations allocate no storage (there's no object being defined), a 
+|> +storage class specifier is useless and superfluous.
+|> 
+|> I disagree violently with the assertion that the issuance of errors for
+|> perfecly "standard conformant" code is "perfectly friendly and very helpful".
+|> Anyone who says such a thing obviously does not port code for a living!
+
+I disagree violently with the assertion that any errors one might make
+would necessarily result in non-standard-conformant code. Just because 
+it's conformant doesn't mean it's intended. Anyone who says such a thing
+obviously never writes original code for a living, or otherwise is a 
+complete programming God who has never made a mistake and never found
+lint to be the least bit useful. 

There is a big difference between using an optional tool like lint, and/or
having warnings which you can *ignore* at your option, and getting *hard*
errors from your compiler for perfectly standard conformant code.

Lint is good.  Warnings are good.  Hard errors for perfectly standard
conformant code are BAD!  I do not wish to have my compiler give me s**t
when I'm trying to port some perfectly standard conforming code.  Nor do
I think that it should be forcing me to change such code, just to get
it to compile and link.

+I would *never* write the above piece of code intentionally, no matter
+how conformant it is, and I would appreciate some kind of warning that
+I had obviously omitted some variable names in those declarations.

As I say, warnings are one thing, and hard errors are another.  Please
do not confuse the two.

-- 

// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra
Technical Details
Message-ID: <1993Jan1.115804.23071@netcom.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!rfg
References: <1992Dec30.173634.15487@crd.ge.com> <1992Dec30.203555.3615@netcom.com> <1992Dec31.150047.22321@crd.ge.com>

Show Full Headers
Complete Article Headers
Newsgroups: comp.std.c
Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!rfg
From: rfg@netcom.com (Ronald F. Guilmette)
Subject: Re: Standard conformance and GCC 2.3.3
Message-ID: <1993Jan1.115804.23071@netcom.com>
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <1992Dec30.173634.15487@crd.ge.com> <1992Dec30.203555.3615@netcom.com> <1992Dec31.150047.22321@crd.ge.com>
Date: Fri, 1 Jan 1993 11:58:04 GMT
Lines: 45