Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!archone!byron
From: byron@archone.tamu.edu (Byron Rakitzis)
Newsgroups: comp.lang.c
Subject: Re: Funny mistake
Message-ID: <13584@helios.TAMU.EDU>
Date: 21 Mar 91 20:36:24 GMT
References: <15481@smoke.brl.mil> <1991Mar16.195153.15509@murdoch.acc.Virginia.EDU> <15490@smoke.brl.mil>
Sender: usenet@helios.TAMU.EDU
Organization: College of Architecture, Texas A&M University.
Lines: 54

In article <15490@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>In article <1991Mar16.195153.15509@murdoch.acc.Virginia.EDU> gsh7w@astsun.astro.Virginia.EDU (Greg Hennessy) writes:
>-#>>"if (a = b)" instead of "if (a == b)". 
>-#>... I have yet to see a UNIX compiler complain about it
>-Doug Gwyn:
>-#That's good, because it is valid C and the compiler cannot know whether
>-#or not it reflects the programmer's intentions.
>-Then perhaps that is why having an optional flag to inform the user of
>-this sometimes suspicious code fragment may be a good idea.
>
>In the world of UNIX, we normally rely on "lint" to generate warnings
>about *possible* problems like this.  The compilers are expected to
>accept conforming translation units and silently translate them.

Flame on:

I think it's time that compilers assumed a greater responsibility in this
direction. How many people remember to run lint on their code? How many do
it at the last minute? I think that one of the best features of gcc is
the -Wall flag; I compile all my code this way, and it has saved my rear
end at compile time countless times.

A "responsible" compiler will flag this if-business as a warning. However,
this will no longer be an ANSI compiler in the Gwynian sense. It will be a
hand-holding compiler that goes out of its way to detect possible glitches in
the code, but if done tastefully, I think it could promote better coding
style in a way that lint has completely failed to do.

I have had uniformly bad experience with lint. Not only is it an outdated
tool (I have not seen an ansi lint) but many of its warnings are not
pertinent to the code. For example, the "pointer alignment" problem with
every call to malloc, and the "returns a value which is ignored" problem
with every call to printf. A user of lint must wade through a whole bunch
of garbage error messages to evaluate whether the code really needs fixing.
And adding gratuitous casts to void before every printf is a solution that's
worse than the problem, IMHO.

I am presently writing (at a snail's pace, unfortunately) a compiler which
will operate at two levels: "pedantic-mode" (the *default*) where it will
try to be picky (in a reasonable way) about both departures from standard
C and from "normal" coding practises (assignments in if statements are on
the verge of obfuscated C, in my opinion; a human reading the code some
time later has to check very thoroughly to make sure that it is in fact
not a typo); and "silent-mode" in which case all warnings are turned off.

The UNIX many-tools philosophy has its uses (I *AM* a many-tools fan), but
I do not think that lint has a place in that toolchest. For one, the
language that a particular compiler implements is rarely the same language
that a tool like lint thinks its checking (cf. the ANSI problem). I
strongly believe it is up to the compiler to take care about safeguarding
the use of the language which it translates, even if this means flagging
valid code which has been *probably* erroneously typed in.

Flame off.