[Greg Woods responding to me]
>> 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,

Worse, there are some that are impossible to _use_ (not "implement")
without either (a) __DECONST or something very much like it, (b) giving
up the benefits of strict const poisoning (ie, dropping -Wcast-qual
-Wwrite-strings or moral equivalent), (c) pulling fragments out into
other modules to be compiled separately without the warning options, or
(d) making (otherwise) unnecessary temporary copies of string literals,
simply to get a de-consted version.

The commonest example in my experience is writev().

> 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've done it on occasion, when it strikes me as the lesser evil - and
unless you've seen the code in question, I don't think you're competent
to hold an opinion on the matter.  The case I remember most clearly,
the alternative seemed to be to duplicate comparatively large amounts
of code merely to have const-poisoned and non-const-poisoned versions
of the same thing.  (Not that I need your approval of my application
code design choices anyway, of course....)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B