Karl Fogel wrote:
I confess I don't understand the nuance of these `const' usages.
The code needs to permute argv; if it can't, we'll have to change the interface, right? If Greg H has to cast internally to get something he can permute, then we might as well not require a const on the castee in the first place.
Does the above declaration still permit permutation of the array? (Apologies; I'm rereading my K&R and still not fully understanding what the above does.)
There's a neat trick to reading C type definitions -- do it right from left, in order of operator binding, starting from the identifier. So when you see
const char *const *blah
you read it as "blah is a pointer to a constant pointer to a character which is const", and
char *argv[]
becomes "argv is an array (yep, binds stronger than dereference) of pointers to char".
Things become clearer now. The other catch is that "const" acts on the object to its right, not the type, and the ambiguity of C's typedefs only confuse more: "const char*" and "char const*" are identical, whereas "const char**" and "char **const" aren't (that's obvious), but people tend to find it confusing, anyway.
It also becomes clear why "argv" isn't declared a "const char**" -- sinply because it wasn't in K&R C, which had no notion of const, and changing that in the standard would break practically every program in existence. There's a lot of such baggage floating around in C, especially in the library (do you love strchr, too?).
(Yes, I've never been able to understand how C, a complex and downright dangerous language to use, could have become so popular over, e.g., Ada. I'd say at least 50% of software bugs arise from C programmers not understanding what they're writing ...)
-- Brane Čibej home: <[EMAIL PROTECTED]> http://www.xbc.nu/brane/ work: <[EMAIL PROTECTED]> http://www.hermes-softlab.com/ ACM: <[EMAIL PROTECTED]> http://www.acm.org/
