default const

[Ed Morton]

Anyone know why "const" isn't the default for function parameters? I almost
never see code where function parameters are modified intentionally (and when I
do, I usually think copying the value to a local variable would be clearer), but
I do occasionally see function parameters being incremented instead of
similair-sounding local variables or, in the case of pointers, instead of the
objects they point to.

e.g.:

void foo(int *x, int link)
{
int lnk = 0;
x++; /* Meant to increment *x */
link++; /* Meant to increment lnk */
....
}

I'm not trying to convince anyone to change the language, just curious about how
it ended up this way.

<OT> Has anyone come across a compiler or other tool that can report warnings
for non-const parameters being modified? </OT>

Ed.

[Eric Sosman]

Ed Morton wrote:

Anyone know why "const" isn't the default for function parameters?
Only an actual member of the committee that wrote the ANSI
standard could answer authoritatively . However, the semantics
of function parameters had been part of C for twenty-odd years
before the ANSI standard brought `const' into the language.
Applying an implicit `const' to function parameters would have
changed those semantics, and would have broken some amount of
code that relied on the old semantics. (And might have led to
a `nonconst' keyword to override the default.)

Now, the committee did introduce new keywords to the language,
and the committee did occasionally introduce semantic changes,
sometimes quiet ones. My speculation is that this particular
change (if it was ever considered at all) probably didn't meet
the committee's "minimal outrage" standard.
I almost
never see code where function parameters are modified intentionally (and when I
do, I usually think copying the value to a local variable would be clearer), but
I do occasionally see function parameters being incremented instead of
similair-sounding local variables or, in the case of pointers, instead of the
objects they point to.

e.g.:

void foo(int *x, int link)
{
int lnk = 0;
x++; /* Meant to increment *x */
link++; /* Meant to increment lnk */
....
}
Programmers are free to choose confusing or misleading
identifiers; the language standard doesn't legistlate style
or good sense.

Also, wouldn't your suggestion of copying `const' parameters
to local variables simply make this kind of confusion more likely?
For example (pardon the syntax):

void foo(int * implicitconst x, int implicitconst link) {
int * nonconst X = x;
while (*X != 0) ++X;
*x = link; /* meant to store to *X */
}

That is, a requirement to copy the parameters would very likely
lead to a profusion of similar-looking names, which in turn might
make it more probable that the programmer accidentally grabs the
wrong member of an associated pair.
I'm not trying to convince anyone to change the language, just
curious about how it ended up this way.

Non-authoritative, but highly suggestive:

"Call by value is an asset, however, not a liability. It
usually leads to more compact programs with fewer extraneous
variables, because arguments can be treated as conveniently
initialized local variables in the called routine."

-- B.W. Kernighan and D.M. Ritchie, "The C Programming
Language" (first edition), section 1.8

--
Er*********@sun .com

[Mike Wahler]

"Ed Morton" <mo************ ****@Lucent.com > wrote in message
news:3F******** ******@Lucent.c om...

Anyone know why "const" isn't the default for function parameters?
I don't *know* why, but I don't see any need.
"Why" can only be answered by Mr. Ritchie and/or
ISO C standard committee members.
I almost
never see code where function parameters are modified intentionally
Yes, its very common that functions do not modify their
parameters. But it is done. I do it on occasion myself.
(and when I
do, I usually think copying the value to a local variable would be clearer),

Note that a function parameter *is* essentially a 'local variable'.
but
I do occasionally see function parameters being incremented
Yes, I do this sometimes. Why create another object when
you don't need to?

int digits(int value)
{
/* no need for a copy of 'value' */
int count = 0;
while(value)
{
++count;
value /= 10; /* modify 'value' */
}

return count;
}
void foo()
{
int i = 42;
int d = digits(i); /* 'i' is not changed */
}
instead of
similair-sounding local variables or, in the case of pointers, instead of the objects they point to.
Modifying the value of a pointer vs its 'target' are
two distinct operations. Which one is done depends
upon the purpose of the function.

e.g.:

void foo(int *x, int link)
{
int lnk = 0;
x++; /* Meant to increment *x */
Then that's simply a coding mistake.
The pointer is incremented, not its target.

But note that many functions with pointer parameters
are indeed written with a 'const' qualifier for
either the pointer or its target (e.g. strcpy(),
strcmp(), etc.)

link++; /* Meant to increment lnk */
Another coding error. But there's nothing wrong with
modifying 'link' (unless of course later code depends
upon the originally passed value.) This is a factor
in my decision whether I'll modify the parameter itself
or first make a copy in a local object. IOW, *think*
about what the function will do before/during writing it.
:-)
....
}

I'm not trying to convince anyone to change the language, just curious about how it ended up this way.
Perhaps the folks over at comp.std.c can give you the
history and rationale about this. That group is about
things like this, this group is for using the language
the way it is.

<OT> Has anyone come across a compiler or other tool that can report warnings for non-const parameters being modified? </OT>

Why should a compiler warn about modifying a nonconst object?
Feel free to define your parameters as const if you feel it
will help you write better code.

-Mike

[Emmanuel Delahaye]

In 'comp.lang.c', "Mike Wahler" <mk******@mkwah ler.net> wrote:

Feel free to define your parameters as const if you feel it
will help you write better code.

I have done that for 6 years now, and yes, I like it, and it makes my code
more solid. I like to say:

"Modifying a parameter is often the sign of a bad design."

or

"The value received as a parameter is as precious as gold. Don't waste it."

--
-ed- em**********@no os.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/