>>> and inevitably you need to be able to discard const without a
>>> simple cast to be safe.

Yes, this is the major problem I find with const poisoning.  I do it
anyway, as I find the benefit much greater than the cost, but I still
need a deconst() for things like loading structs iovec for writev().
(Conceptually, the iov_base pointers for writev should be const, but C
doesn't have a way to do that and still use the same struct for readv
and writev - at least not without making iov_base pointer-to-const,
which has a pile of problems of its own.)

> A far as I know the only sure and portable way to discard a const
> qualifier on some storage area is to allocate new non-const storage
> area and copy the const data into the new non-const storage.

Well, the const qualifier is not really on the storage area in the
cases in question; it's on the pointed-to type of a pointer.

	struct iovec v[3];
...
	v[2].iov_base = "\n";

That assignment is perfectly reasonable provided v is being passed to
writev (as opposed to readv), but it violates const poisoning.  I don't
want to discard const as applied to the storage the string lives in;
the storage _is_ const (and write-protected; I use -fwritable-strings
only when I must, and never in conjunction with const poisoning).

> [...], but the only portable alternative is to qualify the parameter
> as const (and hope it really won't be modified! ;-).

What parameter?  It's the target type of a pointer member of a struct
pointed to by a parameter that's at issue with writev(); other cases
often have the to-be-discarded const buried similarly deeply....

/~\ 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