🚀 go-pugleaf

Frank Adams (adamsf@turing.cs.rpi.edu) writes:
>Warning messages are fine for small programs, where one person can
>read them all and understand them.  ...
>In such a project, one typically has a period "make" or "build", where
>all source changed since the last make (sometimes all source) is compiled.
>...
>For conscientious software engineers, the solution is to treat warnings as
>errors, so that the final program generates no warning messages.  There are
>two problems with this.  The first is that the compiler doesn't help: it
>returns a "success" return code for a compilation with warning messages only,
>so any automated make facility will not detect the error[1].

With the risk of starting OS war here, which is not my intention,
I would like to point out that this is sort of a Unix problem. VMS,
which is the only other operating system I know, helps you on this
one. Unix says zero is OK, the rest is not. (I think, I'm not too 
good on Unix.) VMS uses five levels which are based on the three
lowest bits in the status code. Odd status is success of some sort,
while even is warning, error or fatal error. So if you want to build
your system with warnings you say MMS/NOIGNORE. I don't remember what's
the default, I think it's /IGNORE=WARNING. (MMS is DEC's port of Make
to VMS which you can get for extra bucks.)

>The obvious solution is to make the compiler treat warnings as errors, and
>this is indeed what I am advocating.  But this runs smack into the second
>problem: sometimes, the situation being warned about is exactly what you want
>to do.

Frank Adams then goes with a proposal for C with pragmas to control
which warnings should be flagged and which should not.

I do my daily work with VAX-Pascal and its view what is a warning
and what is an error is not the same as mine. Some warnings are
really important like unitialized variables and function with assign-
ment of the return value. But do we run MMS with /NOIGNORE? Do we
even compile with /WARNING? Pas de chance. I have written modules
on 500-700 lines which generates 70 warnings all to be neglected.
Talk about low signal-to-noise ratio. A facility to kill some of the
warnings could be fine, but in this particular case there are better 
solutions. (See note below.)

For some of the cases of suspected inapproiateness the Pascal
only gives informational message and only if you ask it to. This
inclused unused variables and variables that may be uninitialized.

(What are all these warnings? All of them are for breaking the Pascal
rule that a component of a packed entity may not be passed as a VAR
parameter. This is of course perfectly OK, as long the component is
on even byte boundaries. Now, we're taking a lot of record types from
the CDD (Common Data Dictionary) since the definitions are used outside
Pascal too. Such records are included as PACKED by the %DICTIONARY
directive for some reason. To make matters worse, quadwords (64 bits)
- we have a lot of them, this is a financial system - in such records
are translated to type an empty record which has to be passed as a
VAR parameter. This gives a good deal of all our warnings.)
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Unix is a virus.