Xref: utzoo comp.software-eng:3105 comp.lang.c:26669 comp.lang.misc:4359
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!romp!auschs!awdprime!sanders.austin.ibm.com
From: sanders@sanders.austin.ibm.com (Tony Sanders)
Newsgroups: comp.software-eng,comp.lang.c,comp.lang.misc
Subject: Re: problems/risks due to programming language, stories requested
Summary: use lint
Message-ID: <1719@awdprime.UUCP>
Date: 6 Mar 90 17:05:39 GMT
References: <6960@internal.Apple.COM> <1990Feb28.213543.21748@sun.soe.clarkson.edu> <31039@brunix.UUCP> <48f0d9c2.20b6d@apollo.HP.COM>
Sender: news@awdprime.UUCP
Reply-To: sanders@sanders.austin.ibm.com (Tony Sanders)
Followup-To: comp.software-eng
Organization: IBM AWD, Austin, TX
Lines: 37

Just a coupla comments not directed at Jim but just for the record:

In article <48f0d9c2.20b6d@apollo.HP.COM> perry@apollo.HP.COM (Jim Perry) writes:
>1. A function had an output parameter which was a numeric count, i.e.
>a pointer to an integer.  I wrote the code to increment the count as
>    *count++;
>which of course does entirely the wrong thing (it should be
>"(*count)++;" or, as I rewrote it, "*count += 1;").  Clearly this
>particular mistake is strictly limited to C: in another language this
>parameter would be a reference/out/var, not a pointer; the ++ and
>thus the ambiguity of what's incremented is obviously unique to C; and
This is the same as misunderstanding what "2+3*4" does.  If you assume
it adds 2+3 then multiplys by 4 you'll be sorry.  It's a simple matter
of understanding the precedence rules, thus not limited to C.
FYI: There is a nifty little program called "cparen" for times when you
    are unsure of the precedence.

>of course the stupid notion of unused-expression-as-statement is also
>uncommon.  However, a better C compiler could have flagged the fact of
>the unused expression, i.e. that while "count++" was presumably an
>intended side effect, "*count" was unused.
You have a point that C allows you to have "dangling" expression
(those that have no side effect like "1;" or "*count").  lint will
detect lines that have no effect like "a*b;" but not "*count++;".
I assume that could be added without too much trouble.

>4. A function to allocate, initialize, and return a new node to go in
>...
>probably have done it there.  The absence of a return statement could
>and should have been caught by the compiler.
The absence of a return statement shouldn't have been caught by the compliler,
it should have been and would have been caught with lint (see my new and
improved .sig).

-- sanders                The 11th commandment: "Thou shalt use lint"
Reply-To:  cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders
"she was an innocent bystander, it's a democracy" -- Jim Morrison