[ On Monday, July 14, 2003 at 22:14:21 (+0100), David Laight wrote: ]
> Subject: Re: toolchain/22118: make won't compile with -Wcast-qual -Wstrict-prototypes and more
>
> > But the point remains -- you said you tried adding the the 'const'
> > qualifier to the function parameter in question and then you said you
> > would end up having "to do free(DECONST(pointer))".  Something,
> > somewhere, is very wrong.  (but you've now given me the hint below to
> > show what's wrong -- yes, I should have read the code first, but I
> > didn't)
> 
> But it happens all the time with sequences like:
> 1) allocate a chunk of memory
> 2) fill it
> 3) put the address into a structure for an write/display asynchronous routine
> 4) call the routine
> ... sometime later...
> 5) notification that asynchronous action is complete
> 6) try to free the memory
> 
> Unless you saved the pointer somewhere else, you only have its address
> in a 'const' pointer.

Actually, no, I don't think you do, and if you do then you've declared
the "structure for an write/display asynchronous routine" incorrectly.

Go back to the last 'const' qualifier you added to such a declaration
before you ran into the situation where you think you need DECONST() and
remove it and try another approach.  The apparent need for DECONST()
(especially for something like free()) means you've done something wrong
and you almost certainly have too many 'const' qualifiers in the first
place.

Such problems certainly don't "happen all the time" to me, even though
I've been using "-Wcast-qual -Wstrict-prototypes" for many years now.

In fact I'm not aware of any standard API that mis-uses 'const' in that
way, but if you can show one then maybe we can get it fixed properly.

> Because data areas can become const (ie are not changed once they have
> been initialised) you need to be able to call free() with a const pointer.

But data storage areas cannot "just become" 'const' qualified all by
themselves.  You have to declare the variables, fields, or parameters
into which you store pointers to them as being 'const' qualified, and
presumably if you do that then you know what the heck you're doing.  If
you do go ahead and declare such a pointer as pointing to 'const'
qualified storage then you must, as far as you've bothered to tell the
compiler anyway, be intending to leave that storage as 'const' qualified
from then on.

I.e. You can allow storage to gain the 'const' qualifier, but it doesn't
happen all by iteslf.  With Standard C only(?) string constants start
out in 'const' qualified storage, and with GCC that's true only if you
don't use -fwritable-strings.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>