Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: the "const" qualifier
Message-ID: <11353@smoke.BRL.MIL>
Date: 20 Oct 89 13:56:55 GMT
References: <12239@cit-vax.Caltech.Edu> <11301@smoke.BRL.MIL> <3728@solo10.cs.vu.nl> <11320@smoke.BRL.MIL> <742@ccssrv.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 21

In article <742@ccssrv.UUCP> perry@ccssrv.UUCP (Perry Hutchison) writes:
>It sounds to me like the current "proposed standard" deserves to be voted
>down and sent back to committee to have this mess (and any other problems
>which may have surfaced) cleaned up.

Fortunately for the C programming community, numerous people in a much
better position than you to make such a judgement have decided that the
currently proposed Standard is technically good enough as it now stands.

I'm sorry if you think I described a "mess".  Perhaps that's what I get
for trying to give an honest but brief description of the relevant
history.  In fact there IS NO MESS in this regard in the proposed
Standard.  There IS a void that has been left unfilled, but its effect
is relatively minor.  The two practical consequences will be:

	Occasionally, interface designers will have to decide whether
	or not 	to require a type cast to be used, as in the execve()
	example that started this thread.

	Certain types of optimization will require more complicated
	global flow analysis, or use of nonstandard extensions.