[ On Wednesday, July 16, 2003 at 20:00:15 (+0100), David Laight wrote: ]
> Subject: Re: toolchain/22118: make won't compile with -Wcast-qual -Wstrict-prototypes and more
>
> > K&R 2nd edition states quite emphatically on p. 103:
> > 
> >     The valid pointer operations are assignment of pointer of the same
> >     type, adding or subtracting a pointer and an integer, subtracting or
> >     comparing two pointers to members of the same array, and assigning
> >     or comparing to zero.  All other pointer aritmetic is illegal.
> 
> But that is in the 'prose' part of the book, refer to Appendix A
> section A4.4 (page 196) 'Neither qualifier affects the range of values
> or arithmetic properties of the object.'

What does the "range of values or arithmetic properties of the object"
have to do with whether or not the actual storage area for that address
is either shared with another object, or located in read-only storage,
or both!?!?!?!?!

> > Assigning a "const char *" variable to a "char *" variable requires a
> > cast, but of course that cast discards the 'const' qualifier and thus
> > the warning from '-Wconst-qual'.
> 
> If that were true it would also be an error to assign a 'char *'
> value to 'const char *' variable.

Ah, no, it would not be.

It's irrelevant whether or not a storage area gains a const qualifier
during execution.  The only thing that matters, w.r.t. the utility of
'-Wconst-qual' and the intentions of "const", is when the programmer
tries to discard a const qualifier.  "const" is there (quoting K&R 2nd
ed.) "to announce objects that may be placed in read-only memory".
Assigning a "const char *" value to a "char *" value (or passing the
latter as a parameter declared to be of the former type) does not define
new storage for the pointed to object and thus the pointed to object
must not be placed in read-only storage (or its existing storage marked
read-only) when that assignment or function call happens.

Furthermore discarding a const qualifier by way of pointer aliasing
makes a joke of any attempt to use '-Wconst-qual'.

> Referring to K&R2 section A8.21 (page 211) we also have (right at the
> bottom on the page): 'Except that it should diagnose explicit attempts
> to change const objects, a compiler may ignore these qualifiers.'
> 
> Note that this says 'explicit', not 'make you have to go through hoops to'.

Discarding 'const' in an assignment or during parameter passing are
_exactly_ two of the explicit places where the compiler "should
diagnose" that an attempt may be made to change a const-qualified
object.

If you can invent and implement a Standard C compliant compiler that can
intuit at compile time that a code path to free() will _never_ be
followed (as per the example which started all of this) when a parameter
is a string constant, then I'll be the first to pat you on the back and
buy you a beer to congratulate you.  In the mean time I'm not going to
be holding my breath or anything remotely like that....

-- 
						Greg A. Woods

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