[ On Thursday, July 17, 2003 at 12:34:01 (-0700), Greywolf wrote: ]
> Subject: Re: toolchain/22118: make won't compile with -Wcast-qual  -Wstrict-prototypes and more
>
> In short, the conversation has gone like this:
> 
> Before:	"Well, I don't have standard handy, but I believe it says this..."
> [Standard is quoted, chapter and verse...]
> After:  "Well, nobody follows the standard anymore, and everyone uses GCC,
> 	so the standard is irrelevant."

You forgot a key and critically important part of that conversation:

	"... and portable code must assume ..."

> I would tend to assume no such animal whatsoever in the course of programming,
> for I believe that would fall under the description of "unwarranted
> chumminess with the compiler", as described in K&R.

Portable code cannot assume all compilers are at minimum standards
compatible (and certainly not that they're all standards compliant).
Indeed this whole excercise has been about avoiding implementation
dependencies while at the same time being aware of implementation
quirks.

> "const" causes more headaches than it is supposed to solve, to my even
> as-yet unjaded eye.

Proper use of "const" can be a bit "ugly" (at least to those who don't
like the compiler to tell them how to write their code), but it can
catch real bugs.  It found just such a bug for me the other day in fact
-- a very real bug that was causing core dumps!  That bug would never
have occured in the first place if the original author (not me! :-) had
used "const" carefully and properly.

>  If strings are to be placed into RO storage, great.
> If you're going to write to them, common sense would dictate copying them
> into writable storage and operating on them from there.  If you have
> routines which will both potentially read from and write to the same spot,
> they should not even be HINTED at as being RO.

Once again, no known compiler can predict the runtime behaviour of the
code it compiles.  If you, the programmer, have stated that a function
may write through a pointer parameter (i.e. by _not_ const-qualifying
that parameter, as is the case with free(3), for example), then the
compiler should warn you if you ever try to pass a const-qualified
pointer to that function.  Conversely if you do const-qualify a
parameter and then you try to use it in some way which might result in a
code path that modifies the storage it points to then the compiler
should also warn you of your potential mistake.

Coming full circle to what started this:  the real problem comes from
programmers who are confused about where the "const" qualifier belongs
and where it doesn't and when they are lead to try to do something like:

	free(DECONST(const_ptr));

Such code is _always_ wrong (w.r.t. the way it mis-uses "const").  Such
code will always be susceptible to runtime errors when other coding bugs
result in the wrong kind of pointer being passed to free() (or perhaps
not being passed to free(), depending on circumstances), at least when
it is compiled with a compiler that stores string literals in read-only
storage.

The proposed patch which did something like the following was indeed the
correct solution to the problem:

+	char foo[] = "r";

-	mumble(blah, "r", blurt);
+	mumble(blah, foo, blurt);

-- 
						Greg A. Woods

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