Subject: Re: toolchain/22118: make won't compile with -Wcast-qual -Wstrict-prototypes and more
To: None <tech-toolchain@NetBSD.ORG>
From: Simon J. Gerraty <sjg@crufty.net>
List: tech-toolchain
Date: 07/14/2003 12:17:48
On Mon, 14 Jul 2003 13:25:31 -0400 (EDT), "Greg A. Woods" writes:
>> But eventually you find youself needing to do  free(DECONST(pointer))
>> at which point it all starts to seem silly ;-)

>If a pointer passed to free() may ever have been derived from a string
>constant then there's a very nasty bug lurking somewhere.

Sure, no one is talking about that.  We are talking about the pain
that trying to add const-correctness involves.  The simple fact is
that there are many existing standard api's that do not take const
args - even though they do not modify them,

Within an application you can analyze all your routines, and for those
that do not attempt to modify their args, add const to their
prototypes...   but you eventually come up against api's that are out
of your control and have to do someting sane when interfacing to them.

Make is full of routines that get passed a pointer and a flag that
says "free this when you are done".  The caller is promising that the
arg in that case has been allocated.  Hence the case of
fee(DECONST(pointer)).  The more general point is that at somepoint in
the call change you need to DECONST() when calling a standard api that
will not modify the arg but does not take a const arg.

Even if you felt you had the energy (and copious time) needed to go
fix all the standard/historical api's to be const correct, the
exercise would be of little value since you'd then be non-standard.

Like I hinted at the outset of this thread, retrofitting
const-correctness is an exercise in self abuse.  

--sjg