[comp.lang.c] machine generated code and chatty compilers

wsmith@mdbs.UUCP (Bill Smith) (01/05/90)

For those helpful souls that wish their C or C++ compiler to generate
helpful warning messages in contexts that are technically correct, I 
have another argument that that is inherently a bad idea.

People are not the only entities that generate code for C or C++ compilers.

It is often very useful for a program to generate code in second phase
By doing this, development time for an application is reduced.
If it is convenient for the pre-processor to generate code that is in a
pattern that is a mistake when done by humans, any warnings in such
context will render the rest of the compiler's error checking useless.
(What happens is the compiler generates hundreds of warnings that get
redirected to /dev/null along with any useful and deserved errors that
were generated.)

As a side note, I think one can show that if you had a fortran program
that generated a second fortran program, the two pass execution model
would have equivalent power to any recursive language.  In other words,
one could guarantee that the generated fortran program would never
has stack overflow, which one could not guarantee in a single fortran
program. :-)

Bill Smith
pur-ee!mdbs!wsmith
(not my employer's opinions)

ewiles@netxdev.DHL.COM (Edwin Wiles) (01/06/90)

In article <1471@mdbs.UUCP> wsmith@mdbs.UUCP (Bill Smith) writes:
>For those helpful souls that wish their C or C++ compiler to generate
>helpful warning messages in contexts that are technically correct, I 
>have another argument that that is inherently a bad idea.
>....{edited for brevity}....
>If it is convenient for the pre-processor to generate code that is in a
>pattern that is a mistake when done by humans, any warnings in such
>context will render the rest of the compiler's error checking useless.

1)	If it's a mistake for a human to do it, then it's a mistake for a
	program to do it.

2)	If it's not a mistake, then don't complain about it.

	(Personally, I consider type-mismatches to be mistakes.  Supposedly
	"safe" mismatches have bitten me too often for me to 'ignore' them
	without careful consideration, and even then I'll typecast rather
	than leave a "mistake".)

3)	Any program smart enough to write code should be smart enough to
	avoid things such as type mismatches.  If it isn't, then fix it!
	"Who?... Me?... WHAT opinions?!?"	| Edwin Wiles
    Schedule: (n.) An ever changing nightmare.	| NetExpress, Inc.
  ...!{hadron,sundc,pyrdc,uunet}!netxcom!ewiles	| 1953 Gallows Rd. Suite 300
       ewiles@iad-nxe.global-mis.DHL.COM	| Vienna, VA 22182

bill@twwells.com (T. William Wells) (01/06/90)

In article <2540@netxcom.DHL.COM> ewiles@netxdev.UUCP (Edwin Wiles) writes:
: 1)    If it's a mistake for a human to do it, then it's a mistake for a
:       program to do it.

Human generated code generally must be maintained by a human;
machine generated code is generally not maintained at all. There
is a large class of practices which might be mistakes solely
because they make maintenance harder. If you are not going to
maintain the code, there is no purpose in avoiding those
practices. For machine generated code, those are not mistakes.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

bts@sas.UUCP (Brian T. Schellenberger) (01/07/90)

In article <1471@mdbs.UUCP> wsmith@mdbs.UUCP (Bill Smith) writes:
|People are not the only entities that generate code for C or C++ compilers.

However, they *do* write most of them (maybe not most code, but surely
most programs).  So a good complier should be fairly chatty, especially to
help the poor inocents who are just getting started with C.  Then it should
be easy to turn off the chatiness, both on a single-message basis and by
turning off the whole shootin' match of questionable messages.  Those in
the know will have the werewithall to set up aliases which turn off these
messages all the time; babes in the woods will be saved much grief.

[Lattice compilers, for one (on the Amiga, at least) come pretty close
meeting this ideal, BTW.]  CLAIMER:  I work for Lattice's parent company,
so I may not be objective.
-- 
-- Brian, the Man from Babble-on.		...!mcnc!rti!sas!bts
-- (Brian Schellenberger)
"No one will ever write a song called 'Nitro Burning Funny Cars'"
                 -- THE DEAD MILKMEN, "Nitro Burning Funny Cars"

econrad@thor.wright.edu (Eric Conrad) (01/10/90)

From article <1471@mdbs.UUCP>, by wsmith@mdbs.UUCP (Bill Smith):
> For those helpful souls that wish their C or C++ compiler to generate
> helpful warning messages in contexts that are technically correct, I 
> have another argument that that is inherently a bad idea.
> 
> People are not the only entities that generate code for C or C++ compilers.

So turn the warning suppression flag on for automatic-generated code.

-- Eric Conrad
+----------------------------------------------------------+
| Eric Conrad - Wright State University                    |
| "Progress was all right once, but it went on too long."  |
+----------------------------------------------------------+

exspes@gdr.bath.ac.uk (P E Smee) (01/11/90)

In article <923@thor.wright.EDU> econrad@thor.wright.edu writes:
>From article <1471@mdbs.UUCP>, by wsmith@mdbs.UUCP (Bill Smith):
>> People are not the only entities that generate code for C or C++ compilers.
>
>So turn the warning suppression flag on for automatic-generated code.

This gets to be a religious argument about the proper task for compilers.
My opinion is that the flag should be a 'warning generation' flag.  That
is, by default the warnings should be suppressed; if you want them you
should ask for them.  NOTE that I am talking about WARNINGS, not ERRORS.

My rationale is that the job of a compiler is to take a program source
as input, and to check it *against the language spec*.  If the source
is conformant to the spec, the compiler should silently generate the
appropriate code, as requested by the source generator (be it person, or
tool).  If the source is NOT conformant to the spec, the compiler should
diagnose ALL and ONLY the errors.  (I'll forgive it, though, if SOME
errors screw up its internal state enough that it can't recover, and so
puts out an error and terminates without checking further.)

I would say that if a compiler puts out a warning or error message by
default in response to a VALID piece of code, simply because the
compiler is not convinced that I really wanted to say that, then that
is a bug in the compiler.  The fact the the compiler writer couldn't
see any use for some valid construct does not mean there is no valid
use for it.

The one exception I would be willing to make, is to allow the compiler
also to complain about things which are valid within the language, but
which are (provably at compile time) impossible on the machine for
which it was written.  For example, trying to address an odd location
as an int, if the hardware requires ints to be even-address aligned.

And, as implied at the start, I have no objections to the compiler
allowing you to ask for more warnings; but it shouldn't try to ram them
down your throat.

-- 
Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132
 Smee@bristol.ac.uk  :-)  (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)

henry@utzoo.uucp (Henry Spencer) (01/13/90)

In article <1990Jan11.095715.17262@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes:
>This gets to be a religious argument about the proper task for compilers.
>...
>My rationale is that the job of a compiler is to take a program source
>as input, and to check it *against the language spec*...

It is indeed somewhat of a religious argument.  However, some of us are
not supremely confident of our ability to get everything right (a mere
15 years of C programming experience not being sufficient for that) and 
appreciate any and all help the compiler can supply.  There needs to be
a "shut up, already" switch for dealing with code generated by programs,
or by people who never make mistakes (I've never met one, and I'm afraid
I don't believe you are one, but perhaps I am wrong), but most programs
are written by eminently fallible humans, and a suspicious compiler can
find many errors that would otherwise require extensive debugging.  And
people being what they are, more of those errors will be caught if deep
suspicion is the default than if you have to ask for it explicitly.
-- 
1972: Saturn V #15 flight-ready|     Henry Spencer at U of Toronto Zoology
1990: birds nesting in engines | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

wsmith@mdbs.UUCP (Bill Smith) (01/13/90)

In article <923@thor.wright.EDU>, econrad@thor.wright.edu (Eric Conrad) writes:
> From article <1471@mdbs.UUCP>, by wsmith@mdbs.UUCP (Bill Smith):
> > For those helpful souls that wish their C or C++ compiler to generate
> > helpful warning messages in contexts that are technically correct, I 
> > have another argument that that is inherently a bad idea.
> 
> So turn the warning suppression flag on for automatic-generated code.

On the surface this sounds like a good idea, but the command to turn
of the warnings (when done with a much care as is deserved) will be
incredible complicated to use.

How do you decide which subset of the warning messages to suppress?

To suppress all warnings may hide useful and pertinent warning but
different programming groups may all have mutually disjoint definitions
of "pertinent warnings."

Lint suffers from this effect too.  You can't tweak it to omit just the set
of errors that you don't care to see.

Bill Smith
pur-ee!mdbs!wsmith

econrad@thor.wright.edu (Eric Conrad) (01/13/90)

From article <1990Jan11.095715.17262@gdt.bath.ac.uk>, by exspes@gdr.bath.ac.uk (P E Smee):
> This gets to be a religious argument about the proper task for compilers.

Or a sociological argument.

> My rationale is that the job of a compiler is to take a program source
> as input, and to check it *against the language spec*.  If the source
> is conformant to the spec, the compiler should silently generate the
> appropriate code, as requested by the source generator (be it person, or
> tool).

I would argue that, in order to assure better quality code, human coders
should compile with warnings enabled.  I have yet to see a compiler
issue warnings that should not be investigated.  In the case of
automatically generated code, warnings may not be as significant
because of the need to optimize the target compiler source code.  (I
really don't know if this is an important factor.  I assume that it
must be because of the inclusion of the goto construct in ADA for
similar reasons.)

With warnings off as a default, human users will generally silently
disable warnings by not specifying the warnings option.  Why?  Because
it saves keystrokes.  So for the benefit of human users, I support the
explicit disabling of warnings on the grounds that, if warnings are
disabled, there should be good reason.

Basically then, I feel that a compiler is a software verification
tool as well as a code generation tool.  For example, in ANSI C, it
is legal, for compatibility reasons, to reference functions without
prototypes.  However, doing so increases the likelihood of type
incompatibilities in parameters.  I think that the compiler should
scream unless specifically requested not to.

-- Eric Conrad
+----------------------------------------------------------+
| Eric Conrad - Wright State University                    |
| "Progress was all right once, but it went on too long."  |
+----------------------------------------------------------+

tjr@cbnewsc.ATT.COM (thomas.j.roberts) (01/15/90)

From article <1477@mdbs.UUCP>, by wsmith@mdbs.UUCP (Bill Smith):
> In article <923@thor.wright.EDU>, econrad@thor.wright.edu (Eric Conrad) writes:
>> From article <1471@mdbs.UUCP>, by wsmith@mdbs.UUCP (Bill Smith):
>> So turn the warning suppression flag on for automatic-generated code.
> 
> How do you decide which subset of the warning messages to suppress?
> 
> To suppress all warnings may hide useful and pertinent warning but
> different programming groups may all have mutually disjoint definitions
> of "pertinent warnings."
> 
> Lint suffers from this effect too.  You can't tweak it to omit just the set
> of errors that you don't care to see.
> 

Maybe YOU can't, but many of us can (i.e. those of us using UNIX).
On UNIX, if this really becomes an issue, simply pipe the output
of lint into a suitably-crafted grep command which will remove
all unwanted warnings. While this may not be the most optimal
solution, it would surely be good enough for most uses.

A better solution is to design the automatic code generator to
avoid outputting "lousy" code. That is the approach I have always
taken.

Also: look at TURBO C, for MS-DOS. It has an extensive set of
flags to enable/disable each individual class of warning messages.
As MS-DOS is limited to a 127 character command line, TURBO C
has an initialization file used for command options. I have
never used this feature, as I always rework my code (or code
generator) until no warning or error messages are generated.

Tom Roberts
AT&T Bell Laboratories
att!ihnet!tjr

boyne@hplvli.HP.COM (Art Boyne) (01/18/90)

econrad@thor.wright.edu (Eric Conrad) writes:

>I would argue that, in order to assure better quality code, human coders
>should compile with warnings enabled.  I have yet to see a compiler
>issue warnings that should not be investigated.

The problem is: once you *have* investigated the warnings, how do you
get the compiler to *shut up* on an individual warning in future compiles?
I don't want a global shut-up flag, even on a particular class of errors,
because, in the course of modification, I still might make that class of
error.  Lint does have some comment-directives to tell it to not flag
individual instances of questionable code; ought not the compiler have the
same feature?

Example:  we build instruments at this site, and use a standard parser for
interpreting instrument commands.  It calls all execution routines with
three arguments: input parameter list ptr, output result list ptr, and a
miscellaneous ptr (ie. *in, *out, *misc), where either *in or *out or both
may be null, depending on the command.  Well, that means a lot of routines
never use at least one of the input parameters, and our lousy chatty compiler
generates warnings for *each* unused parameter in *each* routine.  Needless
to say, it is easy to miss a new warning amidst the (numerous) old.

Art Boyne, boyne@hplvla.hp.com

mike@hpfcso.HP.COM (Mike McNelly) (01/19/90)

> >I would argue that, in order to assure better quality code, human coders
> >should compile with warnings enabled.  I have yet to see a compiler
> >issue warnings that should not be investigated.
> 
> The problem is: once you *have* investigated the warnings, how do you
> get the compiler to *shut up* on an individual warning in future compiles?
> I don't want a global shut-up flag, even on a particular class of errors,
> because, in the course of modification, I still might make that class of
> error.  Lint does have some comment-directives to tell it to not flag
> individual instances of questionable code; ought not the compiler have the
> same feature?
> 
> ... 
> 
> Art Boyne, boyne@hplvla.hp.com

As a top-of-the-head suggestion, why don't you send the stderr to a file
and run a sed script on it to remove those errors you're no longer
interested in.  Telling the compiler to avoid warnings on specific line
numbers or specific conditions wouldn't be much easier and you'd stand a
fair chance that something useful might be unintentionally hidden.

Mike McNelly
mike@hpfcla

peter@isgtec.UUCP (Peter Curran) (01/22/90)

In article <340016@hplvli.HP.COM> boyne@hplvli.HP.COM (Art Boyne) writes:
]The problem is: once you *have* investigated the warnings, how do you
]get the compiler to *shut up* on an individual warning in future compiles?
]I don't want a global shut-up flag, even on a particular class of errors,
]because, in the course of modification, I still might make that class of
]error.  Lint does have some comment-directives to tell it to not flag
]individual instances of questionable code; ought not the compiler have the
]same feature?
]
]Example:  we build instruments at this site, and use a standard parser for
]interpreting instrument commands.  It calls all execution routines with
]three arguments: input parameter list ptr, output result list ptr, and a
]miscellaneous ptr (ie. *in, *out, *misc), where either *in or *out or both
]may be null, depending on the command.  Well, that means a lot of routines
]never use at least one of the input parameters, and our lousy chatty compiler
]generates warnings for *each* unused parameter in *each* routine.  Needless
]to say, it is easy to miss a new warning amidst the (numerous) old.
]
]Art Boyne, boyne@hplvla.hp.com


One solution is to add

	assert(parmx == NULL);

for the unused parameters.  This shuts the compiler up (except when you
are compiling the final version for "production" use, by which time you
presumably know that the warnings can be ignored), and has the benefit of
making sure the caller is using the function correctly.  (Of course, it
is technically valid to pass a non-NULL value for the unused parameters,
but I would think it would be good practice to disallow it - when it occurs,
it probably indicates some kind of confusion.)
-- 
Peter Curran       ...uunet!utai!lsuc!isgtec!peter      isgtec!peter@censor
A scientist generates new ideas.  A good engineer makes things work with as
few original ideas as possible.                  - Freeman Dyson
ISG Technologies Inc.   3030 Orlando Dr. Mississauga,  Ont. Canada  L4V 1S8