[ On Friday, July 2, 2004 at 01:36:47 (-0400), der Mouse wrote: ]
> Subject: Re: __UNCONST(a)
>
> Actually, I usually want to strip all qualifiers.  const simply happens
> to be the most relevant one because it's the one for which poisoning is
> most important.  In a few programs I've used a deconst-alike that takes
> const volatile void * and returns void *.

OK, it's one thing that we have standards specified APIs that are
"difficult" to implement in strict Standard C without stripping "const"
qualifiers, but it would seem unnecessary (to the point of being a very
bad practice) for an application author to design an API that also
required similar hacks in order to be implemented "quietly".

I.e if you're designing a function which manipulates pointers and/or
reads values from storage being pointed to, but never changes the
storage being pointed to and which then might return a pointer (in)to
one of the same objects as one of its "const"-qualified parameters
pointed to then why the heck wouldn't you just add the "const" qualifier
to the returned pointer type as well?

I think this hack has been proposed to have the name __DECONST(),
i.e. with the leading double underscores, because it's a strictly
internal hack necessary for quieting compiler warnings that would
otherwise spew forth when compiling the implementations of those very
poorly designed Standard C functions.  This macro should not ever be
visible to the application and should never be used by an application
author.

Normally one should never ever try to fool/trick the compiler into
discarding or ignoring a "const" qualifier.  If you're
"const"-qualifying a pointer, especially one that is a function
parameter, then you should really mean it 100% and if you don't really
mean it then you should not be "const"-qualifying it in the first place.

History has apparently tricked us into suffering with some poorly
designed standard functions, but please let us not add to that mess.

-- 
						Greg A. Woods

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