-=> Roy J. Tellason wrote to William McBrine <=-

 WM> unsigned getshort(const unsigned char *x)
 ...

 RJT> What's the effect of that "const" in there?

 WM> It indicates to the compiler that the value pointed to by x will
 WM> not be modified by getshort(). So this function can take both const
 WM> and non-const parameters. Without it, one might get a warning when
 WM> calling it with a const parameter.

 RJT> So you'd use one when the function is called, to make it match.

NO. What did I just say? "[It] can take both const and non-const
parameters." NOT having to cast the parameters on calling is the whole
point.

There are some commonplace functions that don't modify the values they're
passed, but which are traditionally declared with non-const parameters:

    void somefunc(char *x)
    {
      ...
    }

So when you attempt to pass a const char * to one of these functions, you
have to explicitly cast it, or you'll get a compiler warning:

    const char *y = "whatever";
    ...
    somefunc((char *) y);

Very annoying. But if the function were declared with a const parameter,
there'd be no need to cast when calling it (neither for a const nor
non-const parameter):

    void someotherfunc(const char *x)
    {
      ...
    }

    const char *y = "whatever";
    char z[] = "foo";
    ...
    someotherfunc(y);
    someotherfunc(z);

Of course, the alternative (bad) solution would be to just declare y as a
char * in the first place, even though you never intended to modify it.  
That way, if you accidentally did attempt to modify *y later (think of the
difference between "=" and "=="), the compiler wouldn't
know to warn you
about it; nor would it be able to perform any potential optimizations for
read-only variables if it didn't know they were supposed to be read-only.

... Predestination was doomed from the beginning.
--- MultiMail/Linux v0.45