Path: utzoo!attcan!uunet!mailrus!cs.utexas.edu!usc!orion.oac.uci.edu!uci-ics!rfg
From: rfg@ics.uci.edu (Ron Guilmette)
Newsgroups: comp.lang.c
Subject: Re: Warning messages
Keywords: large projects
Message-ID: <25AFE8A6.14024@paris.ics.uci.edu>
Date: 14 Jan 90 02:49:10 GMT
References: <1471@mdbs.UUCP> <2NNQZ%@rpi.edu>
Reply-To: rfg@ics.uci.edu (Ron Guilmette)
Organization: UC Irvine Department of ICS
Lines: 63

In article <2NNQZ%@rpi.edu> adamsf@turing.cs.rpi.edu (Frank Adams) writes:
>
>For conscientious software engineers, the solution is to treat warnings as
>errors, so that the final program generates no warning messages... 

Agreed.  I always do.

>
>The obvious solution is to make the compiler treat warnings as errors...

Or bettey yet, give the programmer direct control (see below).

>
>To deal with this, I propose introduction of a pragma, with the syntax:
>
>#pragma permit <keyword>

Sorry, but I have to disagree.  I think this is a truly dumb idea.

In an ideal universe, several things would be true which are not necessarily
true now:

	For any type of warning that your compiler could possible emit, there
	would be a simple and easy way of changing the code such that it had
	essentially the same semantics, but did not get the warning.  The
	GNU C compiler seems to measure up to this "requirement" as far
	as I have been able to tell.

	Programmers would be able to control the generation of both warnings
	and (trivially) recoverable errors (like assigning incompatible
	pointers types in C++) in detail.  Normally, there should be a default
	"treatment" for each individual "message".  The "treatment" 
	consists of two independently controlable parts, i.e. (1) the
	"issuance" treatment (should messages for this particular condition
	be issued or suppressed) and the "severity" treatment (should this
	condition be considered to be an error or a warning as far as the
	exit status of the compiler is concerned).  User's should be allowed
	to specify (on a per compilation basis) cases where they wish some
	kind of non-default "treatment" for any particular type of "condition".
	Obviously, one way to do this is via command line options, but I for
	one would probably want to override so many default message treatments
	that it would probably make sense (for me anyway) to be able to have
	my compiler automatically look for either an environment variable or
	for a .treatment file in my home directory which would describe all
	of the zillions of non-default treatments that I personally prefer.

The problem with suppressing and/or enabling warnings and/or errors directly
within the source files themselves is that there is no reason to believe that
the poor dumb son-of-a-bitch who inherits the maintenance responsibilities for
my crappy code after I have died (or changed jobs) will have the same
preferences regarding message treatments that I have (or had).  He may actually
*want* to see all those warnings that I had suppressed (at least while he is
initially trying to figure out what the hell I did).  If they were suppressed
via #pragma's burried in a thousand places in my source files, then this poor
schmuck will have a lot of editing to do.

I think it would be much better to let this other "maintainer" have *his* own
.treatment file in *his* home directory which describes *his* own preferences
for the behavior of compilers.

All power to the programmer!

// rfg