Should function argument be changed in function body?

[Morgan Cheng]

Hi All,

I was taught that argument valuse is not supposed to be changed in
function body. Say, below code is not good.
void foo1(int x)
{
x ++;
printf("x+1 = %d\n", x);
}
It should be "refactor-ed" to be
void foo2(int x)
{
int y = x;
y ++;
printf("x + 1 = %d\n", y);
}

Recently, I found one guy posted code like foo1 in one C lang forum. I
pointed out that it is not good code standard. Surprisingly, seems all
people criticise me as dogmatism. It is claimed that changing arugment
value will not affect caller code and it saves stack size. I understand
their point, but I DO remember it is commmon that argument is not
suppsoed to be changed.

Now I am confused. Is there anybody can give some explaination why it is
a code rule that argument should not be changed?
Thanks & Regards

[CBFalconer]

Morgan Cheng wrote:

.... snip ...
Now I am confused. Is there anybody can give some explaination
why it is a code rule that argument should not be changed?

The only reason not to modify arguments is that the initial value
is required later. Any such rule is pure foolishness. You should
think of arguments as externally initialized local variables (which
is precisely what they are). For example:

int putblanks(size_ t n, FILE *f)
{
while (n--)
if (EOF == putc(' ', f)) return EOF;
return ' ';
}

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Cong Wang]

Morgan Cheng wrote:

Hi All,

I was taught that argument valuse is not supposed to be changed in
function body. Say, below code is not good.
void foo1(int x)
{
x ++;
printf("x+1 = %d\n", x);
}
It should be "refactor-ed" to be
void foo2(int x)
{
int y = x;
y ++;
printf("x + 1 = %d\n", y);
}

Recently, I found one guy posted code like foo1 in one C lang forum. I
pointed out that it is not good code standard. Surprisingly, seems all
people criticise me as dogmatism. It is claimed that changing arugment
value will not affect caller code and it saves stack size. I understand
their point, but I DO remember it is commmon that argument is not
suppsoed to be changed.

Now I am confused. Is there anybody can give some explaination why it is
a code rule that argument should not be changed?
Thanks & Regards

Yeah,changing argument values is really not a good habit.I wanna try to
explain it using asm,though I just BEGIN to learn it.
Use gcc to change the code above into asm, and look for the
differences.You
will find function arguments are pushed into 'stack' and the return
value is in %eax register.If you change the argument in the 4(%esp),it
is bad of course.Er,just so so.
If I am not right,correct this at once! I just have a try! :-(

[Michael Mair]

Morgan Cheng wrote:

Hi All,

I was taught that argument valuse is not supposed to be changed in
function body. Say, below code is not good.
void foo1(int x)
{
x ++;
printf("x+1 = %d\n", x);
}
It should be "refactor-ed" to be
void foo2(int x)
{
int y = x;
y ++;
printf("x + 1 = %d\n", y);
}

Recently, I found one guy posted code like foo1 in one C lang forum. I
pointed out that it is not good code standard. Surprisingly, seems all
people criticise me as dogmatism. It is claimed that changing arugment
value will not affect caller code and it saves stack size. I understand
their point, but I DO remember it is commmon that argument is not
suppsoed to be changed.

Now I am confused. Is there anybody can give some explaination why it is
a code rule that argument should not be changed?

As Chuck Falconer pointed out, the only pragmatical reason _not_ to
change an argument value is that you need it later on.
One _could_ probably argue also that an argument should not be "abused"
for another purpose, e.g. using an argument green_val to store the
result of a completely unrelated computation (instead of introducing
a temporary variable with an apt name, say wobble_factor).
These are the only reasons I can come up with right now.

Making your "rule" into a mandatory rule for a coding standard is indeed
unnecessary dogmatism bordering on sheer folly.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Michael Mair]

Cong Wang wrote:

Morgan Cheng wrote:

Hi All,

I was taught that argument valuse is not supposed to be changed in
function body. Say, below code is not good.
void foo1(int x)
{
x ++;
printf("x+1 = %d\n", x);
}
It should be "refactor-ed" to be
void foo2(int x)
{
int y = x;
y ++;
printf("x + 1 = %d\n", y);
}

Recently, I found one guy posted code like foo1 in one C lang forum. I
pointed out that it is not good code standard. Surprisingly, seems all
people criticise me as dogmatism. It is claimed that changing arugment
value will not affect caller code and it saves stack size. I understand
their point, but I DO remember it is commmon that argument is not
suppsoed to be changed.

Now I am confused. Is there anybody can give some explaination why it is
a code rule that argument should not be changed?

Yeah,changing argument values is really not a good habit.I wanna try to
explain it using asm,though I just BEGIN to learn it.
Use gcc to change the code above into asm, and look for the
differences.You
will find function arguments are pushed into 'stack' and the return
value is in %eax register.If you change the argument in the 4(%esp),it
is bad of course.Er,just so so.
If I am not right,correct this at once! I just have a try! :-(

You are not right.
This is a pseudo-efficiency, pseudo-clarity argument.
C is not assembler, so this does not play a role. At all.
<OT>
Apart from that: Where do you think variables come from/are stored to?
Translating the C code into assembler may well lead to loading an often
used argument into a register, retrieving it only from this register,
nothing forces the compiler to "leave" the variable in the stack.
</OT>

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[pete]

CBFalconer wrote:

Morgan Cheng wrote:

... snip ...

Now I am confused. Is there anybody can give some explaination
why it is a code rule that argument should not be changed?

The only reason not to modify arguments is that the initial value
is required later.

I don't think that's a good reason.
If the specifcation were to suddenly change from the code example

void foo1(int x)
{
x ++;
printf("x+1 = %d\n", x);
}

to
int foo1(int x);
with the return value being the initial value of x,
I would do it this way:

int foo1(int x)
{
const int y = x;

x ++;
printf("x+1 = %d\n", x);
return y;
}

I think the code is easier to read
if the computations use the parameters.

char *str_cpy(char *s1, const char *s2)
{
char *const p1 = s1;

do {
*s1++ = *s2;
} while (*s2++ != '\0');
return p1;
}

If the intial value of a parameter is important,
it's easy to just pop in const qualified object.
Any such rule is pure foolishness. You should
think of arguments as externally initialized local variables (which
is precisely what they are).

--
pete

[CBFalconer]

pete wrote:

CBFalconer wrote:

.... snip ...
The only reason not to modify arguments is that the initial value
is required later.

I don't think that's a good reason.
If the specifcation were to suddenly change from the code example

void foo1(int x)
{
x ++;
printf("x+1 = %d\n", x);
}

to
int foo1(int x);
with the return value being the initial value of x,
I would do it this way:

int foo1(int x)
{
const int y = x;

x ++;
printf("x+1 = %d\n", x);
return y;
}

I wouldn't. What has ++ got to do with anything? I would write:

int foo1(int x) {
printf("x+1 = %d\n", x+1);
return x;
}

easily read by non C programmers and which is also easily modified
to return void. I don't believe in returning the value of entry
parameters anyhow, because that leads to such ugly foulups as:

printf("%s %s\n", b, strcat(b, a));

You will never have this foulup using strlcat.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Morgan Cheng]

CBFalconer wrote:

The only reason not to modify arguments is that the initial value
is required later. Any such rule is pure foolishness. You should
Well, I have some industry experience. All of the code standard requires
that arguments are not to be changed. Even in embedded system
development, this rule is still required. I believe this rule is good
for code maintenance.
think of arguments as externally initialized local variables (which
is precisely what they are). For example:

int putblanks(size_ t n, FILE *f)
{
while (n--)
if (EOF == putc(' ', f)) return EOF;
return ' ';
}

[gooch]

Well, I have some industry experience. All of the code standard requires
that arguments are not to be changed. Even in embedded system
development, this rule is still required. I believe this rule is good
for code maintenance.

Well, I have some industry experience as well and have never come
across this in a coding standard.

[E. Robert Tisdale]

Morgan Cheng wrote:

I was taught that
argument values are not supposed to be changed in function body.
Say, below code is not good.

void foo1(int x) {
++x;
printf("x+1 = %d\n", x);
}

should be "refactor-ed" to be

void foo2(int x) {
int y = x;
++y;
printf("x + 1 = %d\n", y);
}
This is *not* refactoring. You changed the API.
Recently, I found one guy posted code like foo1 in one C lang forum.
I pointed out that it is not good code standard.
Surprisingly, it seems that everybody criticised me as dogmatic.
It is claimed that changing arugment value will not affect caller code
and it saves stack size. I understand their point
but I *do* remember that it is commmon that
argument is not suppsoed to be changed.

Now I am confused. Is there anybody who can give some explaination,
"Why it is a code rule that argument should not be changed?"

There are several possible sources of confusion.
First, a function should *not* modify any of its *actual* arguments.
Instead of

void f(int* p) {
++(*p);
}

you should write

int f(const int* p) {
return *p + 1;
}

The example that you have provided passes by value
so it cannot modify its actual argument.
The *formal* argument is a copy of the *actual* argument.
If the *formal* argument should not be modified,
you should have written

void foo2(const int x) {
int y = x;
++y;
printf("x + 1 = %d\n", y);
}

Strictly speaking, it is up to the programmer
to decide whether [formal] arguments passed by value
are local constants or local variables.
Generally, you will *not* want to make a copy

void foo3(const HugeObjectType* p) {
// Use *p but don't modify it.
}

Your shop may enforce a rule
that generally forbids modifying formal arguments
to avoid accidently modifying actual arguments
(arguments passed by reference [through a pointer])
but objects must sometimes be modified *in-place*

HugeObjectType* foo4(HugeObject Type* p) {
// Modify *p
return p;
}

For example

char *strcpy(char *dest, const char *src);