[ On Tuesday, July 15, 2003 at 23:40:38 (-0700), Simon J. Gerraty wrote: ]
> Subject: Re: toolchain/22118: make won't compile with -Wcast-qual -Wstrict-prototypes and more
>
> >Use of something like DECONST() can _NEVER_ be correct unless it is
> 
> As always, a statement like that is doomed to be wrong.

In this case the only time I could possibly ever be wrong is if the C
standard is changed, or ignored.

> > 'W' on the string constant, 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).  A macro could be used
> 
> I don't think anyone apart from you is talking about that.
> As far as I know - most of us are talking about drawing the line
> _somewhere_ when dealing with 'const'.

Indeed.  I'm proposing this as a potential (non-portable, until the
standard is changed) way of dealing with what seems to be the primary
cause of people's confusion with "const", and with "const char *" in
particular, and as a way to avoid massive abuse of pointer aliasing.  I
suspect it's also the only kind of thing that could ever possibly make
it into the standard.

>  Ie.  there are standard api's out 
> there that take char *, when they could/should take const char *.

The only one that has been revealed to date is XCreatePixmapFromBitmapData()

However I think that one exaimple is grasping desparately at a very few
short and nearly non-existant straws -- how often are use string
constants really used for the parameter in question?  There is not one
single example I can find in /usr/xsrc, for instance.

> So... what do you do when you have a const char *, that you want to pass
> to a routine which takes a char * - but _does_not_modify_it_in_any_way_?
> Re-writing the target function is out.
> Abandoning all use of 'const' is out.
> Copying the data - strcpy, etc is insane for the purpose.
> So what do you do?

Pointer aliasing and broken casts are definitely "out" as possible
solutions too!  They are not portable and they ultimately boil down to
abandoning the most critical uses of 'const' (not all use of course, but
certainly the most critical uses).

I either abandon all use of 'const' (i.e. I don't turn on -Wconst-qual
in the first place and I risk, and sometimes encounter, the occasional
run-time errors when my code attempts to write to read-only storage));
or if I do enable -Wconst-qual then I take the so-called "insane"
approach, since it's really the only sane and possible approach for
people writing and maintaining truly portable code.  In subsequent
analysis of every run-time error I've created it turns out that the
so-called "insane" approach was necessary to avoid the crash in the
first place anyway.

> The rest of us use DECONST() or something like that.

The problem is that all proposed uses of something like DECONST() have
turned out to be very wrong and usually turn out to be a massive abuse
of pointer aliasing under the hood.  If you want to use '-Wconst-qual'
then every proposed DECONST() mechanism (except my 'W' qualifier) will
make the attempted use of '-Wconst-qual' a total joke.

Anything like DECONST() can only ever be properly used if it is applied
directly to a string constant.  This is why I suggest STRONGLY that if a
specific solution to this problem is desirable for NetBSD in particular
then the best solution is to use something like the "W" qualifier I've
proposed for string constants.  That's the only way I can think of which
will not lead to massive abuse of the ability to "de-const-ify" string
constants.

-- 
						Greg A. Woods

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