"6.5.16.1 Simple assignment
...
-- both operands are pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all the qualifiers of the type pointed to by the right;"

*Basically* the first part means that when the two expressions, one on each side of "=", are pointer to X and pointer to Y, then X and Y must be identical (I won't discuss the ways in which they can sort of differ). In particular, X and Y must have "const" in the exact same locations.

The second part says that for the actual pointers (not what they point at), the left one must have "const" "volatile" and "restrict" (ie, the qualifiers) if the right one has any of those (and it can also have any of these even if they are missing on the right).

[Keep in mind that the language of the C99 standard is not simple, and it is difficult to explain accurately without quoting a huge amount of stuff. I am trying.]

That same section then continues with an example just to show that the thing being pointed to must match (basically) exactly, ie, X and Y must be qualified identically.

If given:
"const char **cpp;
char *p;"

Then further down in the application, the following would be INcorrect:
"cpp = &p // constraint violation"

The expression on the right "&p" is a pointer to "char*" which is not the same as "const char*" which is what the left side points to. Thus we violate the first part of the rule at the top by not having the pointer on the left point to something with the same type as that which the pointer on the right points.

Now another example.

It would be fine to then add the following:
"char*const*r = &p;"

since each of these points to plain old "char*". In this case the left pointer is const while the right one is not, but that is ok according to the second part of the rule at the top.

What you can't have according to the second part of the rule at the top is a nonconst pointer (on the left) accepting the value of a const pointer (on the right) as this shows:

char *const*xxx = ....; //ie, set xxx to something legitimate and this will be xxx's value forever.
char **yyy;
//yyy = xxx //bad because const pointer on right but not on left.

And do note that yyy and xxx point to compatible types "char*". In this example we only violated the second part of the rule not the first.

So you want the things being pointed to to be the same and you want the left pointer to be const if the right one is const.

More pseudocode examples:
const char ***const** = const char ***const** //fine, they are identical in all respects
const char ***const*const* = const char ***const** //fine because right need not be a const pointer
const char ***const*const* = const char ***const*const* //fine, they are identical in all respects
const char ***const** = const char ***const*const* //bad because left must be const pointer if right is const pointer
const char ***const** = char ***const** //bad because the type pointed to on the left does not match the one pointed at the right (const char ... vs char ...)
const char ***const** = const char **const** //bad because the types pointed to don't match. Note that the right is one "*" short.
const char ***const** = const char **const*** //bad again since they still don't match.

If I say:

    const char my_const_string[] = "Hello world";

then my_const_string refers to an object (the text "Hello world") defined with a const-qualified type. Definition refers to providing the body of the object, e.g. its initializer. Since the const-ness of the object is known at compile time, the compiler and/or linker can put that object into read-only storage, or do other optimizations such as string-packing.

Compare that to:

   const char *const_string_ptr;

Here, const_string_ptr itself is not const (the pointer can be made to point anywhere at runtime), but whatever it points to should be treated as const when referred to by that pointer variable. It says nothing else about other pointers that might point to an object that that pointer points to. Suppose then I have the following:

   const char *const_string_ptr;
   char       *string_ptr;
   char        my_writeable_string[] = "Hello world";

   /* ... */

   string_ptr       = my_writeable_string;
   const_string_ptr = my_writeable_string;

This is perfectly fine. And, if I write *string_ptr = 'J', that will change the string to read "Jello world", which is just fine, and completely legal. The existence of a pointer-to-const that happens to point to this string doesn't make it illegal. If I were to go a step further and say:

    const_string_ptr = my_writeable_string;
    /* ... */
    string_ptr       = (char *)const_string_ptr;
    *string_ptr      = 'M';

That's where things look iffier, but only because we've exceeded the ability of C's type system to catch programming errors. In this case, since const_string_ptr was initialized with a pointer to writeable storage, it happens to be legal, although one could argue it's a violation of interface. (Rather than casting away const, a proper interface might instead keep both const and non-const versions of the pointer around.) In this specific example, the code correctly changes the string to read "Mello world".

If const_string_ptr actually was initialized with a pointer to an actual const-defined object (such as my_const_string in my very first example), then this is an error that will lead to undefined results. The fact that the cast above makes it impossible for the compiler to distinguish the two is the reason I say we've exceeded the type system's ability to detect programming errors. In recent GCCs, -fwriteable-strings is deprecated, which implies that GCC makes an effort to move these const strings into read-only storage. That also implies that you could get whacked with a segmentation fault if you try to write to one.

What that also means is the old practice of writing something like this now gives you warnings or errors (if you turn your warning level up or request C99), because it's technically incorrect code:

    char *dodgy_string = "Hello world";

This does not allocate writeable storage for the string "Hello world", and in fact is throwing away const. That's why I wrote char my_writeable_string[] above, because that form does allocate writeable storage for the string.

--
Program Intellivision and play Space Patrol!

Generally (IIRC), undefined behavior means you are not following the spec

When you invoke undefined behavior, it means just that; the behavior of what you're doing is not defined. The result of evaluating a[i++] = i++; can be having your program print 42 or delete all files in the current directory. Both are equally valid results (though not very likely, I'll admit ;-) ).

Implementation defined behavior, however, generally means you're just losing portability. The behavior is defined by the implementation, and is therefore subject to change between implementations (even between versions of the same implementation, so it's a really bad idea to rely on implementation defined behavior).

However, things do seem to work a bit differently in kernel land than in user land, and for many there are more important things in life than following the C specification to the letter ;-)

I believe that C99 "feature / behavior" you described above does not represent an "evolution / improving" of the C standard / functionality, but an adaptation to help / protect the more growing number of 'programmers' who do not understand the real(logical) purpose of const. The explicit affirmation "the behavior is undefined" states it clearly from my point of view that it is more of an 'crafty - job' than an well designed mechanism. P.S. Of course that i'm not 'such an expert' either but i have a feeling that if you deny this term to Linus you definitely cannot qualify the iso c99 boys for it

Grandparent got it right, you misread him.

In any case, passing a non-inline function a "some_type *const some_var" parameter is often meaningless, since the pointer itself is local and changing it cannot possibly effect anything outside of the said function.

If you really wanted to you could pass all pointers as "*const" and use them as read only bases for any pointer manipulations you wanted to carry out using other local stack variables.

As for casting away "const", well that should **IMHO** only be valid on pointers other fundamental/primitive types for which working with some reference (Be it C++ references or pointers) is just as expensive in terms of memory and CPU time as taking a copy.

Linus is absolutely correct that "const" has no meaning when it comes to differentiating "invalidating" and "modifying" the pointer target, as used in a free() function.

const is sometimes incompatible with dynamic memory allocation. some structure may be constant throughout most of your program, but at one point you have to initialize the memory your const* points to. you can achive that by allocating a pointer to non const first and only assign the initialized contents, but depending on your data structures or program logic (e.g. memory allocation of a generic structure vs. initialization for a special purpose; allocations from a free list that contained pre-allocated but uninitialized structures) this may be impossible without tricks like having a special version of the structure without const annotated internal pointers (best generated with preprocessor trickery...). and of course you have to free the structures after use. how do you NULL out your 'this must never be changed' const*const pointer after having freed the data it points to (i hope you don't like dangling pointers), how did you free the data in the first place?

another problem is demonstrated by char *strchr(const char *s, int c); : strchr("hello", 'h') returns a non-const-pointer to read-only memory, i.e. casts const char* to char*. if you want to change that, you can't use the function for purposes where you want to change the string, e.g. to implement something like strtok(...). do you want 2 versions of the function, one with const result, one without? how should the non-const version check if you called it with a string that should be const? should functions never return pointers but only size_t offsets to their arguments, which makes the handling more complicated and un-C-like?

const is an important hint for error prevention and optimization, but it must be possible to override it in controlled situations, else you can't use it at all.

The difference here seems to be that Torvalds (and apparently you) doesn't regard invalidation as equal to modification. Conversely storing known values into a previously uninitialized chunk of memory makes that bit of memory's contents known, i.e. validates that memory, and that is certainly modification.

It's a matter of convention, see? When a new reference-counted object is created, it is returned with exactly one reference, that's also a convention. The convention with regard to a free() call used by Linux is just weirder than common sense when C is used as an application programming language.

nah, just kidding :)

few early morning 0xD/*eep*/D/*own*/ public asserts:

firmware == test case for ko(s) /* manufacturers insist on adding to their proprietary gizmos */
user land == excellent test case for ___THE ___kernel
C89/99/09/19/x9/etc == ansi test cases for gcc __extensions /* actually very deep :) */
C++ == VMT centric test case for C // with BCPL style comments and fixed ideas about encapsulation
STL == standard evidence that encapsulation decapsulates algorithms from data structs /* C */

have a nice day
d