[ On Tuesday, July 15, 2003 at 13:18:38 (-0400), der Mouse wrote: ]
> Subject: Re: toolchain/22118: make won't compile with -Wcast-qual -Wstrict-prototypes and more
>
> > const-qualified storage can never be portably de-const-ified,
> 
> No.  But pointer-to-const can be portably converted to
> pointer-to-nonconst.

That's called pointer aliasing and it bypasses the very checks proper
use of "const" is intended to allow.

I fully realize there's no portable way not to have string constants
stored in const-qualified storage, but then again that's the whole point
in the first place.

All string constants _may_ be stored in read-only storage and thus to
use them in portable code it's necessary (at least if you want your code
to be portable and strictly standards compliant) to always copy string
constants to writable storage before passing/assigning a pointer to the
latter via/to any pointer which does not point to const-qualified
storage.


> > If your API requires string constants to be writable ...
> 
> You appear to be confusing "writable string constant" with "non-const
> pointer to string constant".  Generating the latter (eg, with my
> deconst()) does not produce the former; it appears that you think I
> think it does.  If so, you are wrong; I know it doesn't, and that's not
> what I'm trying to achieve by using deconst().

No, I'm most certainly not confusing these things.  String constants
are, and MUST always have, a type which indicates that they are stored
in const-qualified storage.

The whole point of using "const" is to warn you when you might end up
trying to pass a pointer to a function which _may_ sometimes try to
write to the storage being pointed to (or to assign one pointer to
another which may eventually somehow be used by or passed to some code
which may sometimes write to that storage area).

> You keep claiming this, but you never back it up.  Please cite chapter
> and verse explaining how my deconst() violates the standard.  (Not,
> note, using deconst() *and then writing through the result*.)

I don't have a final copy of any C standard, but I do have Harbison and
Steele's book "C: A Reference Manual", and I do have nearly twenty years
of writing portable C code using many different compilers, including
many different ANSI/ISO compatible compilers.

"const" is there to give you a _compile_time_ warning about the
_potential_ for writing to read-only storage thus portable and safe use
of "const" requires that you never alias a pointer behind the compiler's
back.  If you're going to use pointer aliasing to avoid compiler
warnings then you may as well simply not even try to use "const" in the
first place and as such you cannot consider your code to be portable and
compliant with Standard C which effectively requires that you use
"const" and that you use it properly and completely.

-- 
						Greg A. Woods

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