Function Practice Questions

When Line 1 ($double \ foo(double);$) is removed, the compiler encounters the function call $foo(da)$ in $main$ before encountering the function definition. In C, failing to declare a function before use results in an implicit declaration, which historically assumes $\int \ foo()$. When the compiler subsequently reaches the actual definition $double \ foo(double \ a)$, it detects a critical conflict between the implicitly declared return type (int$) and the actual definition return type ($double$). Consequently, modern compilers treat this type mismatch or the implicit declaration violation as a fatal compilation error. Thus, the code fails to compile.

To analyze the declaration int (*f)(int *);:

1. The grouping (*f) uses parentheses to ensure the dereference operator * binds to $f$, identifying $f$ as a pointer.
2. The suffix (int *) defines the function signature, indicating the pointed-to function accepts an $\int *$ as an argument.
3. The prefix $\int$ defines the return type of the function that $f$ points to.
4. Therefore, $f$ is a pointer to a function that accepts an $\int *$ and returns an $\int$.

To reverse an input string using recursion, the function must read characters and push them onto the call stack until a newline character is encountered.

1. Inside wrt_it, we need to read a character into the local variable c and check if it is not a newline ('\n'). This is achieved by (c=getchar()) != '\n'.
2. If this condition is met (the input is not a newline), the function calls itself recursively (wrt_it()), effectively storing the current character on the stack.
3. Once the recursion base case is reached (newline is input), the calls begin to return.
4. ?2 is then executed during the stack unwinding process. By calling putchar(c), the stored characters are printed in the reverse order of their input (Last-In, First-Out).

The function uses a static variable i that retains its value across recursive calls.

1. f(1): Since $1 < 5$, $n$ becomes $1 + 1 = 2$ and $i$ becomes $2$. Calls f(2).
2. f(2): Since $2 < 5$, $n$ becomes $2 + 2 = 4$ and $i$ becomes $3$. Calls f(4).
3. f(4): Since $4 < 5$, $n$ becomes $4 + 3 = 7$ and $i$ becomes $4$. Calls f(7).
4. f(7): Since $7 \ge 5$, the function returns $n = 7$.

The static variable $y$ in $funcg$ retains its value across calls, starting at $10$.
In iteration 1 ($count=1$): $funcf(5)$ calls $funcg(5)$ ($y$ becomes $11$, returns $11+5=16$), then $funcg(5)$ is called again ($y$ becomes $12$, returns $12+5=17$). The total $y = 10 + 16 + 17 = 43$.
In iteration 2 ($count=2$): $funcf(5)$ calls $funcg(5)$ ($y$ becomes $13$, returns $13+5=18$), then $funcg(5)$ is called again ($y$ becomes $14$, returns $14+5=19$). The total $y = 43 + 18 + 19 = 80$.
The program outputs the updated values of $y$ in each iteration: 43 and 80.

The program initializes struct $s$ with $s.a = "A"$ and $s.b = "B"$, leading to the first output: $A \ B$.

When calling $f1(s)$, the struct is passed by value, creating a local copy. Modifications $s.a = "U"$ and $s.b = "V"$ affect only this local copy, resulting in the second output: $U \ V$.

Returning to $main$, the struct $s$ remains unchanged, so the third output is the original values: $A \ B$.

Finally, $f2(\&s)$ is called with a pointer to $s$. The operations $p \to a = "V"$ and $p \to b = "W"$ modify the original struct $s$ in $main$, resulting in the fourth output: $V \ W$.

The complete sequence is "A B", "U V", "A B", "V W".

The function void swap(int a, int b) uses pass-by-value semantics, where the formal parameters $a$ and $b$ act as local copies of the actual arguments $x$ and $y$. Executing the swap logic inside the function merely exchanges these local copies, leaving the original variables $x$ and $y$ in the calling scope unmodified. Since the function lacks access to the memory addresses of the original variables, it cannot affect the values held in the caller's scope. Thus, the function is ineffective for swapping because the parameters are passed by value.

Under static scoping, global variables $i=100$ and $j=5$ are used in the expression $i+j$. In the call-by-need mechanism, the parameter $x$ is a thunk that evaluates the expression $i+j$ only upon its first access and memoizes the result.

1. The first print(x + 10) triggers the evaluation of $x$: $i + j = 100 + 5 = 105$. The result is $105 + 10 = 115$.
2. The value $105$ is cached for $x$.
3. Updating $j$ to $20$ does not change the already memoized value of $x$.
4. The second print(x) outputs the cached value $105$.
   The values printed are $115$ and $105$.

1. Initialize global $x = 5$. Call $P(\&x)$ passing the address of global $x$.
2. Inside $P$, create a local variable $x = *y + 2 = 5 + 2 = 7$. Call $Q(7)$.
3. Inside $Q(7)$, the parameter $z = 7$. Adding the global variable $x=5$ gives $z = 7 + 5 = 12$. $Q$ prints $12$.
4. Back in $P$, update the value at address $y$ (global $x$): $*y = 7 - 1 = 6$. Global $x$ is now $6$.
5. $P$ prints its local $x$, which remains $7$.
6. Finally, $main$ prints the modified global $x$, which is $6$. The sequence is $12, 7, 6$.

The programming language uses call-by-name, so the formal parameter $x$ is substituted by the expression $i + j$. With dynamic scoping, variables are resolved based on the current execution stack.

1. In the call $P(i + j)$, the expression $x = i + j$ is passed.
2. Before the local declaration int i = 10 is in effect, the first $print(x + 10)$ evaluates $i$ and $j$ in the global scope: $100 + 5 + 10 = 115$.
3. After the statements i = 200 and j = 20 execute, the local $i$ becomes $200$ and the global $j$ becomes $20$.
4. The second $print(x)$ evaluates $x = i + j$ using the current scope (local $i = 200$, global $j = 20$), yielding $200 + 20 = 220$.

The printed values are $115$ and $220$.

Under the value-result convention, an actual parameter is copied into the function upon invocation and copied back to the caller's location only upon successful function completion. In contrast, the reference convention allows the function to access and modify the actual memory location of the parameter directly throughout execution. When an exception occurs before the function completes normally, the copy-back step for value-result is skipped, leaving the caller's variable unchanged. However, reference passing retains any partial modifications made to the variable prior to the exception. Thus, the final values of the actual parameters will differ between these conventions in the presence of an exception.

In program $P1$, we have $x = 10$ and $y = 3$. The call func1(y, x, x) passes these variables by reference, creating aliases for the formal parameters $(x, y, z)$ within func1:

1. The formal parameter $x$ aliases the actual argument $y$ (value $3$).
2. The formal parameter $y$ aliases the actual argument $x$ (value $10$).
3. The formal parameter $z$ aliases the actual argument $x$ (value $10$).
   Inside func1:

• y = y + 4 updates the actual argument $x$: $x = 10 + 4 = 14$.
• z = x + y + z updates the actual argument $x$ using the current values: $z = (\text{value of } x_{param}) + (\text{value of } y_{param}) + (\text{value of } z_{param}) = 3 + 14 + 14 = 31$.
  Thus, $x$ becomes $31$ and $y$ remains $3$. The print statements output $31, 3$.

1. The global variable $n$ is initialized to 10 in the main program.
2. Procedure $D$ declares a local variable $n$ and initializes it to 3.
3. $D$ calls procedure $W$ with $n$ passed by reference, binding $W$'s parameter $x$ to $D$'s local $n$.
4. Inside $W$, the operation $x = x + 1$ updates $D$'s local $n$ from 3 to 4.
5. Procedure $W$ prints the value of $x$, which is 4.
6. Since 4 is not among the provided options (10, 11, 3), the result is "None of the above".

[P1] returns the address of a local variable $x$, which is deallocated upon function return, resulting in a dangling pointer.
[P2] dereferences an uninitialized pointer $px$, leading to undefined behavior or a segmentation fault because $px$ points to an indeterminate memory address.
[P3] correctly allocates memory on the heap using malloc, which persists after the function returns, making this operation safe.
Consequently, only [P1] and [P2] are problematic functions.

The incr function uses a static variable $count$ which retains its value across function calls, initialized to $0$.
The for loop runs for $i \in \{0, 1, 2, 3, 4\}$, updating $count$ via the operation $count = count + i$ and assigning the result to $j$.
The execution steps are:
$i=0: count=0, j=0$; $i=1: count=1, j=1$; $i=2: count=3, j=3$;
$i=3: count=6, j=6$; $i=4: count=10, j=10$.
After the loop terminates, the final value of $j$ is $10$.

In dynamic scoping, variable references resolve to the most recent binding within the active call stack rather than the lexical scope. First, when show is called from the global block, it references the global $x$, which is set to $0.25$, outputting $0.25$. Second, small is called, which defines a local variable $x$ and sets it to $0.125$. When show is subsequently invoked within small, it searches the call stack and resolves to the most recent binding of $x$, which is the local $0.125$. Thus, the program prints $0.25$ followed by $0.125$.

The function Trial(a, b, c) attempts to return the median by swapping parameters, but it contains a flaw regarding termination. Specifically:

1. The first condition (a >= b) && (c < b) checks if $b$ is the median (where $c < b \le a$) and returns $b$.
2. For inputs like $a=b=c=2$, the condition (a >= b) is true, but (c < b) is false, triggering the else if branch Trial(a, c, b), which becomes Trial(2, 2, 2).
3. This leads to infinite recursion because the arguments do not change in a way that satisfies the base case.
4. Since the function fails to terminate for certain inputs (e.g., when $a=b=c$), it cannot consistently represent the median, maximum, or minimum of the inputs.

Therefore, the function does not correctly perform any of the listed operations for all valid inputs.

The given function is the McCarthy 91 function, defined as $f(x) = x - 10$ for $x > 100$ and $f(x) = f(f(x+11))$ for $x \leq 100$.
For $x=95$:
$fun(95) = fun(fun(106)) = fun(96)$
$fun(96) = fun(fun(107)) = fun(97)$
Continuing this recursive pattern, we see that $fun(n) = fun(n+1)$ until reaching $n=100$.
Finally, $fun(100) = fun(fun(111)) = fun(101) = 101 - 10 = 91$.
Therefore, the function returns 91.