> Use of something like DECONST() can _NEVER_ be correct unless it is
> _ONLY_ ever applied DIRECTLY to string constants (or equivalent ...).

Oddly enough, when I look at where I use it, I am almost always
applying it directly to string constants.

> Any time you've run into a situation where you need to use such a
> construct in an assignment or on a parameter value then something is
> gravely wrong somewhere.

...huh?  What's "gravely wrong" with

	v[2].iov_base = deconst("\n");

> [It would be better to do something else], rather than to try to
> pretend that there's some magic macro which can be used portably to
> make string constants writable (because as yet there is no such
> thing).

No, of course not.  I'm not trying to make the string constant's data
writable.  I am suppressing a warning that I know is noise; that is all
I am trying to do, and I believe that is all I'm doing.

>> I consider this better, because it becomes possible to turn [such
>> warnings] off piecemeal, only where they need to be turned off,
>> without having to pull the affected code into a separate file to be
>> built with different flags.
> However nothing like this can be done portably, at least not until,
> and unless, the C standard is changed to allow for this to be done.

What is standard-violating about the deconst() I quoted?  (Attempting
to write through the resulting non-consted pointer would be a
violation, of course, as it attempts to write into storage that may not
be writable.  That's not relevant to what I asked.)

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