Subject: Re: __UNCONST(a)
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 07/02/2004 14:43:20
[ 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
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 <email@example.com>
Planix, Inc. <firstname.lastname@example.org> Secrets of the Weird <email@example.com>