On Mon, Jul 14, 2003 at 10:14:21PM +0100, David Laight wrote:

> Greg Woods wrote:
> > Something, somewhere, is very wrong.

I find myself agreeing with greg here...

> But it happens all the time with sequences like:
> 1) allocate a chunk of 
> 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.

but if you didn't know that a priori, then all bets are off.  and by
definition, the only function that does know about it ahead of time is
the one that constified it in the first place.  which means it needs be
responsible for de-constifying it before passing to free().

> 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.

that's absurd.  the caller is the one who made the mess by constifying
the variable; let it undo its mess by de-constifying it with a cast.

free((void *)notreallyaconstpointerbutwepretendeditwas);

I assume we're talking about structures with const members:

struct {
	int somevariable;
	const char *pointertoconstdata;
} foo;

and that the member is getting assigned like so:

foo.pointertoconstdata = (const char *)malloc(somesize);

seems like the caller should see a different struct than the callee.
that way the constification could happen at the function call just like
with single variables.

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier@poofygoof.com
  "Isn't an OS that openly and proudly admits to come directly from Holy
   UNIX better than a cheap UNIX copycat that needs to be sued in court
   to determine what the hell it really is?"  --  Michael Sokolov