C questions

[sophia.agnes]

Dear all,

I was going through a C book written by an indian author
the following are the questions given in that book

1) consider the following statement:
s1 : an operator may require an lvalue operand, yet yield an r
value
s2: an operator may accept an rvalue operand , yet gives an lvalue

which of the following is true about s1 and s2

(a) both s1 and s2 are true
(b) only s1 correct
(c) only s2 is correct
(d) both are false

answer is given as (a)

& is one such operator
int n;
*n is lvalue
&n is rvalue

operator operand result
& n is l value &n rvalue

* (p + 1) is r value *(p + 1) lvalue
2) which of the following is false

a) a string has type array of characters
b) a string has storage class static
c) adjacent string literals are concatenated into a single string
d) Concatenation of ordinary and wide string literal is a single
string

answer is given as d option

3)consider the following

process1(int counter)
{

if(counter == 1)
{
char buf[80];
--------------
}
}

process2(int counter)
{
char buff[80];
if(counter == 1)
{
--------
}

}

which one of the following is true

(a) both process require same stack space in all cases
(b) process 1 require more stack space
(c) process 2 require more stack space
(d) stack space for process is not allocated if counter == 1

answer is given as a option

4) consider the following statements

s1: evaluating the address of an object value after indirection is
simply object
s2:evaluating an object value from indirecting after taking its
address is not the object

which of the following is true
(a) only s1
(b) both are correct
(c) only s2 is correct
(d) both are wrong

answer is given as b option

5)which operation require more memory access
(a) branch
(b) conditional code test
(c) shift register right /* what is this ?*/
(d) all are same

answer is given as d option

well what do you folks think of all this stuff ?

[sophia.agnes]

On Jan 7, 10:07 pm, Harald van D©¦k <true...@gmail. comwrote:

On Mon, 07 Jan 2008 08:50:08 -0800, sophia.agnes wrote:

2) which of the following is false

4) consider the following statements

s1: evaluating the address of an object value after indirection is
simply object
s2:evaluating an object value from indirecting after taking its address
is not the object

I don't understand these statements. When x is an object, *&x is
completely equivalent to x, and when x is a pointer, &*x is equivalent to
x, except that it is not an lvalue.

This is what you meant is n't it ?

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

int main(void)
{

int *x,n=10;
x = &n;

if( &*x == x)
puts("EQUAL");
else
puts("NOT EQUAL");

printf("\n *x = %p",*x);
printf("\n &n = %p",&n);

return(EXIT_SUC CESS);
}

I am getting output as
EQUAL

*x = 0xa
&n = 0xbf84e8a0

now can you make it clear that why &*x isn't a l value ?
is it because we can't assign to it or any other reason ?

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Mon, 07 Jan 2008 22:48:19 -0800, sophia.agnes wrote:

now can you make it clear that why &*x isn't a l value ? is it because
we can't assign to it or any other reason ?

It's the other way around: we can't assign to it because it isn't an
lvalue. It's an expression that is not directly formed by reading an
object. It's the same way that x+0 isn't an lvalue, even though for most
arithmetic types, it's otherwise completely equivalent.

What would you expect & &*x to mean? Would you want it to give you a
pointer to x? If you would, then where do you stop? Consider x+0 again,
would you consider that an lvalue? And if so, how about when x is of type
short (so x+0 is of type int)? I'm not saying it couldn't be done, but
getting all the details right would be far more trouble than it's worth.

[Keith Thompson]

ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:

In article <88************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

[...]

>>& can take the name of a function, which is far from being an lvalue!

Though you are of course right about that, the answer does come close
to the *idea* of lvalues. The idea of an lvalue is that it's
something on the left-hand side of an assignment - something that can
be assigned to - a place rather than a value. The ability to take the
address of something clearly implies that it is a place.

The fact that you can't say

int foo(void) {...}
int bar(void) {...}
...
foo = bar;

is not really any different from the situation with

int foo[10];
int bar[10];
...
foo = bar;

so there's no real reason why function names should not be considered
lvalues just as array names are.

There is a real reason: an lvalue designates an object, and a function
is not an object. Whether that's a real *good* reason is another
question.

--
Keith Thompson (The_Other_Keit h) <ks***@mib.or g>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[James Kuyper]

Ravishankar S wrote:

<so**********@g mail.comwrote in message
news:3e******** *************** ***********@n22 g2000prh.google groups.com...

>Dear all,

I was going through a C book written by an indian author
the following are the questions given in that book

Would be interesting for me to know which book this is ?

>1) consider the following statement:
s1 : an operator may require an lvalue operand, yet yield an r
value

To be specific , the question applies to unary operators only ? Then the &
operator is one such:
&n is a an rvalue. For a binary operators I can think of a == b

That doesn't qualify, because "==" does not require an lvalue operand.

On the other hand, "=" does require an lvalue operand, and I've already
given a=3 as ane example.

>4) consider the following statements

s1: evaluating the address of an object value after indirection is
simply object

>s2:evaluatin g an object value from indirecting after taking its
address is not the object

*&(x) == x and &*(x) != x
Is this what is meant by the complicated language ??

No, equality applies to values. The clearest way to show that an
expression refers to an object is to use the expression to assign a
value to the object it refers to, though this only applies to modifiable
lvalues. As far as I can tell what he's saying is that:

int i, *p;

// s1: Take address after performing indirection.
// Since &(*p) supposedly refers to an object, this
// should not be a constraint violation:
&(*p) = &i;

// s2: Perform indirection after taking address
// Since *(&i) supposedly does not refer to an object,
// this should be a constraint violation:
*(&i) = 3;

>which of the following is true
(a) only s1
(b) both are correct
(c) only s2 is correct
(d) both are wrong

answer is given as b option

If I'm correct about what the author meant, he's got it exactly backwards.