[ On Wednesday, July 16, 2003 at 15:30:02 (-0400), der Mouse wrote: ]
> Subject: Re: toolchain/22118: make won't compile with -Wcast-qual -Wstrict-prototypes and more
>
> Unfortunately for your argument, not all read-only storage has
> const-qualified type.

If that is so then I believe it would be a bug in the implemenation.

Even though GCC isn't strictly standards compliant, it does not,
according to Mr. Taylor, put string constants used as array initializers
in read-only storage but it does (with -Wconst-qual) warn whenever a
pointer to a string constant might accidentally lose its implied const
qualifier.

If you can show me a concrete example of read-only storage that does not
implicitly or otherwise have a const qualifier then perhaps we can
explore this line of your reasoning further.

> > Note also that there is no distinction in Standard C (though there
> > seems to be in GCC's implementation) between a definition in the form
> > "char foo[]" and a definition in the form "char *foo".
> 
> This is true when - and ONLY when - foo is a formal parameter to a
> function.

No, not only....   See K&R 2nd ed. page 99:

	In evaluating a[i], C converts it to *(a+i) immediately; the two
	forms are equivalent.

Array notation in C is, effectively, just a macro to convert a more
human readable notation into pointer arithmetic.  C doesn't really have
arrays as first-class language components.

> I don't know where you got this delusion that all read-only storage
> must have a const-qualified type, but it doesn't agree with any other
> reference I've ever found.

I don't know which references you've relied upon, but read-only storage
really must be const-qualified in order to make -Wconst-qual warnings be
of any use whatsoever.

>  What's more, it has nothing whatever to do
> with adding const to a pointed-to type and then removing it later when
> you know the original pointer was actually non-const, something you
> seem convinced is verboten, but have never explained why.

You seem to be assuming that compilers, such as GCC which implements the
recommended (at least by K&R) warnings of const violations, can somehow
intuit not only the undeclarable intentions of the programmer (well,
actually it's the programmer who is violating his or her own explicit
declarations, but we'll leave that alone for now) and the runtime
behaviour of of the code.

"const" is there to provide a compile-time diagnostic and as such the
compiler must conservatively assume that when the programmer tries to
pass or assign a pointer to const-qualified storage off to a parameter
or other pointer that is not const-qualified then there's been a mistake
somewhere and a warning must be generated.  As far as I can see all
these warnings from GCC about 'const' being discarded are the very best
that can be done by any compiler without the assistance of an omipotent
being, or at the very least the use of time travel.  If you don't like
these warnings then turn them off.  If you like these warnings but at
times you would rather they don't appear then separate the code where
you know you're doing something that use of "const" cannot possibly
diagnose accurately into a separate compilation unit and either turn off
those warnings for that compilation unit, or better yet use
'-fwritable-strings' for that compilation unit.  However even if you
really think you know better than the compiler let me remind you that
you still risk runtime errors from coding mistakes, especially if you
end up using a compiler that is only strictly standards compliant and
which does, like GCC does by default, combine identical string constants
and/or place them in read-only storage.  The only sure way to avoid
those runtime errors is to discard const in the only way it can be
properly discarded in Standard C, which is to copy the data in question
over to a new storage area that's guaranteed one way or another to be
writable.

-- 
						Greg A. Woods

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