[ On Friday, July 18, 2003 at 13:53:22 (-0400), der Mouse wrote: ]
> Subject: Re: toolchain/22118: make won't compile with -Wcast-qual -Wstrict-prototypes and more
>
> > [...Greg Woods rehashing of the same old positions again...]
> 
> Your conceptual const appears to amount to "read-only storage", and as
> such is tied only loosely to the actual C const qualifier.

No, not "only loosely" and not only for read-only storage (though
conceptually I suppose "read-only" covers the gamut).

The whole purpose of the "const" qualifier in the first place is to help
the compiler know when to warn the programmer that he or she (or a
Standard-define API) has declared that a code path _may_ result in an
attempt to modify a constant, including a string literal constant.  This
is desirable because the Standard C language allows its implementations
to use read-only and/or shared storage for constants.

>  You appear
> to want a language in which the compiler prevents you from doing
> anything that could ever possibly lead to your writing into read-only
> storage.

I have never said any such thing.  What I do want, and with GCC what I
do have, is an implementation of Standard C which gives me the ability
to know at compile time whether or not my code could potentially suffer
a bug that might result in an attempt to modify a constant.  Luckily
with GCC on NetBSD I also have a runtime environment which will help me
more quickly detect and diagnose bugs in other people's code which do
end up attempting to modify constants because they've mis-used or abused
the "const" qualifier.

>  C is not such a language; its design philosophy is to permit
> the programmer to use tools like const to help the programming process,
> but not to turn them into straitjackets.

I'm extremely well aware of the design philosophy of the C language, as
I am also well aware of the advantages and limitations this philosophy
imposes on programmers using the C language.  This is why I've tried to
point out that using pointer aliasing to bypass "const" warnings is an
abuse of the ability of "const" to warn when problems may occur.

>  If you really want the sort
> of no-escape discipline you seem to think const should provide,

I do not necessarily want that and I never said I did.

I also have not claimed "const" provides a no-escape discipline.  It
should be quite clear to all that "const" is merely advice to the
compiler about what the programmer believes the code will do and that
the warnings in return are merely advice to the programmer based on what
advice the programmer has given the compiler in the form of "const"
declarations.  The only time I can think of at the moment that the
compiler can force "const" advice on the programmer is with the implied
type of string literals, and I know from experience that the programmer
would be stupid to ignore, or work to disable, such advice.  I have
(even recently) fixed bugs which were caused either by programmers
ignoring such advice, or which were latent in code written before
"const" was commonly available (and needed) for this purpose.

"const" would not have been necessary if the ANSI committee had done
their job properly and standardized the original C language instead of
inventing a new variant language.  (K&R, 1st edition, Appendix A, 2.5
(p.181):  "All strings, even when written identically, are distinct.")

> you
> would probably be happier with some other language.

Hmmm -- yes, such as, for example, Smalltalk-80 or even Common LISP.

>  In any case, I
> cannot see why you make such a point of trying to fit C as used by
> other people into your vision of what a language should be;

I am most certainly not trying to describe an ideal language -- as C is
anything but.  I am discussing the situation in the real-world for C
code that attempts to be portable regardless of whether the target
implementations it is to be compiled with are themselves strictly
compliant with the C Standard or not.

I've also been attempting to clarify the point I tried to make in my
very first reply and weed out the noise caused by the many reactions
which apparently mis-interpreted that first point.

That very first point I tried to make was primarily that any attempt to
invent a DECONST() macro/function/cast/whatever was clearly and
blatantly wrong on all counts and secondarliy that the very attempt to
justify such a construct always relies only on some earlier mistake
caused by either trying to add a "const" qualifier to a parameter where
it did not belong or else making the mistake of assuming that string
literal constants were not at least implicitly "const"-qualified.

I.e. if you think you need DECONST() then you are mistaken as the real
problem is elsewhere.  So far nobody has demonstrated even a hint of a
standard (de facto or otherwise) API which mis-uses "const" and thus
would require DECONST() tricks to either implement or use it without
changing the original API (minutely, and in an ABI-compatible fashion).

> yet you don't
> (seem to) get all torqued up about that; why over C?

I'm trying to prevent you and others from inventing and disseminating a
construct that is blatantly wrong and which will result in far more
problems than it appears to initially solve, and if I can't do that then
I at least want to make it as obvious as possible to others why such a
construct is very wrong.

Luckily most of this discussion is academic, at least w.r.t. "make",
given the apparent solution to the PR which started it all.

I'm also very happy to learn from this discussion that GCC's use of
writable storage for "char foo[]" initializers is likely to be mirrored
by other conforming Standard C implementations.  Up until now this was
something I had assumed was a GCC specific behaviour and would may not
be copied by a strictly conforming implementation.

(I suppose I also get somewhat worked up over this kind of issue because
of the fact that it would have been avoided in the first place if ANSI C
had not invented new and strictly unnecessary constructs such as shared
storage for string literals.  Grrr.  :-)

-- 
						Greg A. Woods

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