chris@mimsy.UUCP (Chris Torek) (01/09/88)
In article <609@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: >... Claiming that its the programmer at fault won't, help you when your >software clashes [orange software for a red button? :-) ] >causing major damage (as in a Venus probe that had a bug in the >software to the degree: for i=1.100 in Fortran ). Actually, the most accurate reports as to the legendary Venus Probe Bug indicate that the problem was a missing hyphen, not a dot changed to a comma. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 ????) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
nick@ccicpg.UUCP (Nick Crossley) (01/12/88)
I too have often made the error of writing if (a = b) rather than if (a == b),
and was in the position of having to check a lot of my own code and that of
several co-workers on a large project. So I wrote a program 'check' which
checked the things lint did not, based on the errors I saw in our code.
'check' will produce a warning for :-
= in any conditional context
potentially ambiguous else
if with neither then nor else
The first checks for = not only in if, but while, for, &&, ||, etc.
The second warns about :-
if (a)
if (b)
stat1;
else stat2;
but not about :-
if (a)
{
if (b)
stat1;
else stat2;
}
which I believe to be better (and since I wrote the program, I made it think
as I do :-))
The third warns about :-
if (a);
stat1;
which is legal, but dubious, and which one of my co-workers wrote, and which
took me a good day of debugging to notice the extra semicolon!!
'check' is by no means complete; there are many additional features I will
get round to adding one day, including software metrics. However, it works
fine as it stands, so if anyone is interested I can post it.
Nick Crossley
...!uunet!ccicpg!nick
CCI, 9801 Muirlands, Irvine 92718mitt@hpclroy.HP.COM (Roy Mittendorff) (01/14/88)
Yes, I am interested. Please post it.
Roy. {hpda,hplabs,hpfcla}!hpcllca!mitt
USMail: Hewlett-Packard, M/S 47Lh
19447 Pruneridge Ave;
Cupertino, CA 95014-9974ray@micomvax.UUCP (Ray Dunn) (01/21/88)
In article <8971@ccicpg.UUCP> @ccicpg.UUCP (Nick Crossley) writes: >I too have often made the error of writing if (a = b) rather than if (a == b), >... So I wrote a program 'check' which checked the things lint did not ... >... >The third warns about :- > if (a); > stat1; >which is legal, but dubious, and which one of my co-workers wrote, and which >took me a good day of debugging to notice the extra semicolon!! Ah yes, and then there is, for example: fn1 ("paramstring 1", 57); fn2 ("paramstring 2", 23); for (i = 1; i < 100; i++); fn3 (argument, i); Which has TWICE taken me a similar time to find (You'd think I'd learn!) This leads me into the whole question of formatted and indented source, which I feel has some serious risks involved with it. Indentation is IGNORED by Lint and the compiler, but is superficially VERY significant to we visually oriented beings. Thus the occasional problem in spotting the above class of errors. Aren't we in a very similar situation here to the oft complained about "blanks are ignored problem" of Fortran, which played its part in the space craft lost "do 10 i = 1.3" (perhaps) myth? The best solution I have seen to date, is an intelligent editor (C+ mode extension to EMACS) which always *automatically* indents your line to the correct position by context. I have often had syntax errors and the above situation found at source entry time using this method. Perhaps the integrated development environments we are now seeing (e.g. Turbo-C etc) should pay more attention to this aspect of the environment? Ray Dunn. ..philabs!micomvax!ray
rcvie@tuvie (ELIN Forsch.z.) (01/25/88)
In article <887@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >... >Indentation is IGNORED by Lint and the compiler, but is superficially VERY >significant to we visually oriented beings. Thus the occasional problem >in spotting the above class of errors. >... Perhaps you try a better lint! We use Gimpel's which handles indentation, the ==/= problem, etc. We detected many of these cryptic errors that way. Dietmar Weickert, ALCATEL-ELIN Research Center, Vienna, Austria.
john@frog.UUCP (John Woods, Software) (01/27/88)
In article <887@micomvax.UUCP>, ray@micomvax.UUCP (Ray Dunn) writes: > In article <8971@ccicpg.UUCP> @ccicpg.UUCP (Nick Crossley) writes: > >The third warns about :- > > if (a); > > stat1; > >which is legal, but dubious > Ah yes, and then there is, for example: > fn1 ("paramstring 1", 57); > fn2 ("paramstring 2", 23); > for (i = 1; i < 100; i++); > fn3 (argument, i); > Which has TWICE taken me a similar time to find (You'd think I'd learn!) > Indentation is IGNORED by Lint and the compiler, but is superficially VERY > significant to we visually oriented beings. Thus the occasional problem > in spotting the above class of errors. As it happens, there was an article some years back in (I think) SIGPLAN (but I'm extremely unsure) about a PASCAL compiler that had been modified to REMOVE the begin and end keywords -- block structure was indicated by indentation, and ONLY by indentation! I suppose, though, that this trick would have less applicability in C, where macros can be used to hide the keywords and even to invent blocks in the middle of nowhere. -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw@eddie.mit.edu "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart
jdc@naucse.UUCP (John Campbell) (01/28/88)
In article <567@tuvie>, rcvie@tuvie (ELIN Forsch.z.) writes: > In article <887@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: > >... > >Indentation is IGNORED by Lint and the compiler, ... > >... > > Perhaps you try a better lint! We use Gimpel's ... Ok! Hold it! Can someone summarize all available lint's? I thought there was a pcc based lint that some netters have been passing mods around for and a few commercial lints and that was it. Has lint been collecting unnoticed? Especially, who is writing gnulint (anybody)? -- John Campbell ...!arizona!naucse!jdc unix? Sure send me a dozen, all different colors.
news@ism780c.UUCP (News system) (01/29/88)
>> >Indentation is IGNORED by Lint and the compiler, ... >> >... >> >> Perhaps you try a better lint! We use Gimpel's ... > >Ok! Hold it! Can someone summarize all available lint's? Looks to me that the time is ripe of an ANSI lint standard. This would solve all our problems :-) Marv Rubinstein