Writing functions to prove that variables cannot be changed by another function.

It is said that variables in a function cannot be changed by another function. Only by using pointers can variable values be changed.

I am writing some functions to try to prove this theory, but I can't get it right.

Code:

---

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    int x = 10;
    printf("default x value is %d\n",x);
    try1(x);
    printf("x after try1 is %d\n", x);
    try2(&x);
    printf("x after try2 is %d\n", x);
   
    return 0;
}

---

Code:

---

#include <stdio.h>

void try1(int x){
    printf("x in try1 is %d\n", x);
    x++;
    printf("x in try1 after ++ is %d\n", x);
}

void try2(int *x){
    printf("x in try2 is %d\n", *x);
    *x++;
    printf("x in try2 after ++ is %d\n", *x); // Error, always gives me the address memory number
}

---

try

Code:

---

(*x)++

---

Quote:

---

Originally Posted by Krabiki

It is said that variables in a function cannot be changed by another function. Only by using pointers can variable values be changed.

---

Or in the case of bad code using a bad index on an array. Example program. Volatile is used to force x to be located on stack to prevent compiler optimizer from using an immediate value instead of x:

Code:

---

#include <stdio.h>

void modifyx(void);

int main()
{
    volatile int x = 1234;
    printf("original value of x %d\n", x);
    modifyx();
    printf("modified value of x %d\n", x);

    return(0);
}

void modifyx(void)
{
    volatile int y[1];
    int i;

    for(i = 0; i < 30; i++){
        if(y[i] == 1234)
            y[i] = 4321;
    }
}

---

output

Code:

---

original value of x 1234
modified value of x 4321

---

Quote:

---

Originally Posted by vart

try

Code:

---

(*x)++

---

---

Thanks a lot. Hmm why is the parentheses required in this case ?

Wow rcgldr, thanks for the example, the volatile keyword sounds foreign to me though haha =)

Quote:

---

Originally Posted by Krabiki

Thanks a lot. Hmm why is the parentheses required in this case ?

---

It had to do with the precedence of the operators * and ++.
Without the parentheses, you increment the pointer that is pointing to the variable x.
With the parentheses, you say, go bring me the value that the pointer is pointing to and THEN increment what you brought me, thus the value. Of course, since we use the ++ operator, then the value is stored where the pointer points to.

Quote:

---

Originally Posted by std10093

It had to do with the precedence of the operators * and ++.
Without the parentheses, you increment the pointer that is pointing to the variable x.
With the parentheses, you say, go bring me the value that the pointer is pointing to and THEN increment what you brought me, thus the value. Of course, since we use the ++ operator, then the value is stored where the pointer points to.

---

Oh thanks for the explanation. Didn't thought of operator precedence being the issue =)

Quote:

---

Originally Posted by rcgldr

Or in the case of bad code using a bad index on an array. Example program. Volatile is used to force x to be located on stack to prevent compiler optimizer from using an immediate value instead of x:

Code:

---

#include <stdio.h>

void modifyx(void);

int main()
{
    volatile int x = 1234;
    printf("original value of x %d\n", x);
    modifyx();
    printf("modified value of x %d\n", x);

    return(0);
}

void modifyx(void)
{
    volatile int y[1];
    int i;

    for(i = 0; i < 30; i++){
        if(y[i] == 1234)
            y[i] = 4321;
    }
}

---

output

Code:

---

original value of x 1234
modified value of x 4321

---

---

That example is undefined behaviour, and pure evil. It could destroy other data on the stack that it should not be touching, not to mention it makes an assumption about the direction of the stack, which is false under other architectures. So in some cases it would not work at all. And then there' the issue that it may be accessing memory outside the bounds of the stack. Or if run under an interpreter you'd probably get who knows what kind of horrible issues.

Ugh, that's so horribly evil that you've done a disservice by posting it at all.

Basically "volatile" adds nothing useful to the conversation. If the variable not not have its address taken from the scope it exists in, then for all intents nad purposes, no other code can modify its value. It's as simple as that.

Quote:

---

Originally Posted by iMalc

That example is undefined behaviour.

---

The point was to prove that is its possible to change a variable due to a faulty function. In this case a malicious function was used, but a similar thing could happen due to a programming error.

I have an issue with the original premise of "writing functions to prove that variables cannot be changed by another function", since this is an attempt to prove a "negative" (proving that that something doesn't exist), by creating a set of functions. How large would a set of functions have to be in order to prove "that variables cannot be changed by another function"?

Quote:

---

Originally Posted by iMalc

Basically "volatile" adds nothing useful to the conversation.

---

In the case of microsoft compiler with optimizations enabled, then without the "volatile", there is no instance of the variable "x", instead "x" is replaced by with an immediate value of 1234 by the compiler. I could have used some other method to force the compiler to create an instance of "x", but volatile was the simplest way.

Quote:

---

Originally Posted by rcgldr

I have an issue with the original premise of "writing functions to prove that variables cannot be changed by another function", since this is an attempt to prove a "negative" (proving that that something doesn't exist), by creating a set of functions. How large would a set of functions have to be in order to prove "that variables cannot be changed by another function"?

---

Only three, by engineer's induction: if the variable declared in main cannot be changed by try1, try2, and try3, then it cannot be changed by any other function. Duh!

Quote:

---

Originally Posted by rcgldr

I have an issue with the original premise of "writing functions to prove that variables cannot be changed by another function", since this is an attempt to prove a "negative" (proving that that something doesn't exist), by creating a set of functions. How large would a set of functions have to be in order to prove "that variables cannot be changed by another function"?

---

Quote:

---

Originally Posted by laserlight

Only three, by engineer's induction: if the variable declared in main cannot be changed by try1, try2, and try3, then it cannot be changed by any other function.

---

I did a search for "engineer's induction" and all I find are joke sites. Do you have a link for "engineer's induction" that explains what this is?

Rather than trying to prove a negative with some set of functions, it seems it should just be stated that the rules of C and C++ prevent proper functions with defined behavior from modifying the variables of other functions unless some form of pointer or reference is involved.

The function I created disproves the premise that functions can't modify variable in other functions, but it did so by exploiting an out of range index, which is not a proper function.

I think that was actually a joke lol. Wow, the first time I've ever seen one on the C board not made by me. It's a new day!

Quote:

---

Originally Posted by rcgldr

Rather than trying to prove a negative with some set of functions, it seems it should just be stated that the rules of C and C++ prevent proper functions with defined behavior from modifying the variables of other functions unless some form of pointer or reference is involved.

---

Indeed, you were correct earlier that no amount of negative results disproves a positive.

Yes it should just be stated that the language rules disallow it, e.g. as I tried to in post 8.

Quote:

---

Originally Posted by MutantJohn

I think that was actually a joke lol. Wow, the first time I've ever seen one on the C board not made by me. It's a new day!

---

It's not that unusual - here's an example:

http://cboard.cprogramming.com/gener...uh-cliche.html