some tricky questions

[birensubudhi]

1) void foo(char *s,char *t)
{
while(*s++=*t++);


}

which C function is equivalent to foo ?

2) #define ROUND(x,n)

((x+n-1)&(~(n-1)))
what is hte value of ROUND(223,64) ?
DESCRIBE IT HOW IT IS SO?

3) void foo(int x)
{
int i=0;
while(x)
{
x=x&(x-1);
i++;
}
printf("%d",i);
}
what is the o/p of this function & why it is so ?
what function does this '&' does ?
4) union{
int i;
char c[sizeof(int)];
}x;
x.i=1;
if(x.c[0]==1)
printf("the m/c is _______________ endian");
else
printf("the m/c is _______________ endian");

fill in the blanks with tthe correct option:
a) little,big b)big,big
c) big,little d)little,little

5) int fun2(char *a,char *b)
{
for(; *a==*b;a++,b++)
if(*a=='\0')
return 0;

return *a-*b;
}
char a[10]="date",b[10]="data";

what is the value of fun2(a,b)?

 

[Tor Rustad]

1) void foo(char *s,char *t)
{
while(*s++=*t++);


}

which C function is equivalent to foo ?

FYI, we don't do homework.

 

[Army1987]

1) void foo(char *s,char *t)
{
while(*s++=*t++);


}

which C function is equivalent to foo ?

None. strcpy returns a char* equal to its first argument. Also, the
second argument of strcpy is a const char*.

2) #define ROUND(x,n)

((x+n-1)&(~(n-1)))
what is hte value of ROUND(223,64) ?
DESCRIBE IT HOW IT IS SO?

It is the value of ((223+64-1)&(~(64-1))), of course.

3) void foo(int x)
{
int i=0;
while(x)
{
x=x&(x-1);
i++;
}
printf("%d",i);
}
what is the o/p of this function & why it is so ?
what function does this '&' does ?

If x is INT_MIN, it is allowed to make demons fly out of your nose.
BTW, what is an o/p? And the '&' does no "function", at least in the C
sense.

4) union{
int i;
char c[sizeof(int)];
}x;
x.i=1;
if(x.c[0]==1)
printf("the m/c is _______________ endian");
else
printf("the m/c is _______________ endian");

fill in the blanks with tthe correct option:
a) little,big b)big,big
c) big,little d)little,little

Nope. It could be middle endian. And if I'm not wrong, the standard
specifies nothing about the bit order. On a conforming implementation, it
could be sizeof (int) == 2 && CHAR_BIT ==8, and
the first byte of i could contain the first, third, fifth, seventh,
ninth, eleventh, thirteenth, and fifteenth bit in that order, and
the second byte could contain the sixteenth, fourteenth, ..., second bit in
that order.

5) int fun2(char *a,char *b)
{
for(; *a==*b;a++,b++)
if(*a=='\0')
return 0;

return *a-*b;
}
char a[10]="date",b[10]="data";

what is the value of fun2(a,b)?

It is 'e' - 'a', which nothing requires to be four. It could be
anything from CHAR_MIN - CHAR_MAX to -1 included, and it could be
anything from 1 to CHAR_MAX - CHAR_MIN included. Not all the world
uses ASCII.

 

[per9000]

<[email protected]> ha scritto nel messaggio
[...]

2) #define ROUND(x,n)

((x+n-1)&(~(n-1)))
what is hte value of ROUND(223,64) ?
DESCRIBE IT HOW IT IS SO?

It is the value of ((223+64-1)&(~(64-1))), of course.
[...]

The reason: "by definition".
[]-|--<

/Per

--

Per Erik Strandberg
home: www.pererikstrandberg.se
work: www.incf.org
also: www.spongswedencare.se

 

[Kenny McCormack]

1) void foo(char *s,char *t)
{
while(*s++=*t++);


}

which C function is equivalent to foo ?

What is homework, Alex?

 

[Keith Thompson]

1) void foo(char *s,char *t)
{
while(*s++=*t++);


}

which C function is equivalent to foo ?

foo.

 

[Robert Gamble]

1) void foo(char *s,char *t)
{
while(*s++=*t++);

which C function is equivalent to foo ?

None. strcpy returns a char* equal to its first argument. Also, the
second argument of strcpy is a const char*.

2) #define ROUND(x,n)

((x+n-1)&(~(n-1)))
what is hte value of ROUND(223,64) ?
DESCRIBE IT HOW IT IS SO?

It is the value of ((223+64-1)&(~(64-1))), of course.

3) void foo(int x)
{
int i=0;
while(x)
{
x=x&(x-1);
i++;
}
printf("%d",i);
}
what is the o/p of this function & why it is so ?
what function does this '&' does ?

If x is INT_MIN, it is allowed to make demons fly out of your nose.
BTW, what is an o/p? And the '&' does no "function", at least in the C
sense.

4) union{
int i;
char c[sizeof(int)];
}x;
x.i=1;
if(x.c[0]==1)
printf("the m/c is _______________ endian");
else
printf("the m/c is _______________ endian");

fill in the blanks with tthe correct option:
a) little,big b)big,big
c) big,little d)little,little

Nope. It could be middle endian.
Right.

And if I'm not wrong, the standard
specifies nothing about the bit order. On a conforming implementation, it
could be sizeof (int) == 2 && CHAR_BIT ==8, and
the first byte of i could contain the first, third, fifth, seventh,
ninth, eleventh, thirteenth, and fifteenth bit in that order, and
the second byte could contain the sixteenth, fourteenth, ..., second bit in
that order.

Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.

Robert Gamble

 

[Richard]

FYI, we don't do homework.

Who is "we"? Because someone else did.

 

[Mark McIntyre]

Who is "we"? Because someone else did.

Did'ja read the answers? Not entirely likely to pass the homework
test...

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Tor Rustad]

[...]

FYI, we don't do homework.

Who is "we"? Because someone else did.

I exclude spammers, and that someone else was spamming in my view.

 

[Army1987]

Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.

Unless the actual standard differs from n1124.pdf, it says:
If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N?1), [...]
Nowhere does it says anything about how are these ordered. Maybe
on the DS9K this is decided randomly at program startup.

 

[Robert Gamble]

Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.

Unless the actual standard differs from n1124.pdf, it says:
If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N?1), [...]
Nowhere does it says anything about how are these ordered.

Let me know when you make it through the second half of that sentence.

Robert Gamble

 

[Mark McIntyre]

And if I'm not wrong, the standard
specifies nothing about the bit order. On a conforming implementation, it
could be sizeof (int) == 2 && CHAR_BIT ==8, and
the first byte of i could contain the first, third, fifth, seventh,
ninth, eleventh, thirteenth, and fifteenth bit in that order, and
the second byte could contain the sixteenth, fourteenth, ..., second bit
in
that order.

Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.

Unless the actual standard differs from n1124.pdf, it says:
If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N?1), [...]
Nowhere does it says anything about how are these ordered.

Let me know when you make it through the second half of that sentence.

The second half of the sentence doesn't say ", with the powers of two
being ordered sequentially throughout each octet".

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Robert Gamble]

"Robert Gamble" <[email protected]> ha scritto nel messaggio
And if I'm not wrong, the standard
specifies nothing about the bit order. On a conforming implementation, it
could be sizeof (int) == 2 && CHAR_BIT ==8, and
the first byte of i could contain the first, third, fifth, seventh,
ninth, eleventh, thirteenth, and fifteenth bit in that order, and
the second byte could contain the sixteenth, fourteenth, ..., second bit
in
that order.
Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.
Unless the actual standard differs from n1124.pdf, it says:
If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N?1), [...]
Nowhere does it says anything about how are these ordered.

Let me know when you make it through the second half of that sentence.

The second half of the sentence doesn't say ", with the powers of two
being ordered sequentially throughout each octet".

The full sentence says:
"If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2N 1, so that objects of that type shall be
capable of
representing values from 0 to 2N 1 using a pure binary
representation; this shall be
^^^^^ ^ ^^^^ ^^^^^^
^^^^^^^^^^^^^^
known as the value representation."

Robert Gammble

 

[Mark McIntyre]

"Robert Gamble" <[email protected]> ha scritto nel messaggionews:[email protected]...

And if I'm not wrong, the standard
specifies nothing about the bit order. On a conforming implementation, it
could be sizeof (int) == 2 && CHAR_BIT ==8, and
the first byte of i could contain the first, third, fifth, seventh,
ninth, eleventh, thirteenth, and fifteenth bit in that order, and
the second byte could contain the sixteenth, fourteenth, ..., second bit
in
that order.

Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.

Unless the actual standard differs from n1124.pdf, it says:
If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N?1), [...]
Nowhere does it says anything about how are these ordered.

Let me know when you make it through the second half of that sentence.

The second half of the sentence doesn't say ", with the powers of two
being ordered sequentially throughout each octet".

The full sentence says:
"If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2N 1, so that objects of that type shall be
capable of
representing values from 0 to 2N 1 using a pure binary
representation; this shall be
^^^^^ ^ ^^^^ ^^^^^^
^^^^^^^^^^^^^^
known as the value representation."

Assuming you underlined the "pure binary representation", it +still+
doesn't say the bits have to be in ascending or descending order.
Indeed I suspect we all know some implementations where this isn't the
case.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.

Unless the actual standard differs from n1124.pdf, it says:
If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N?1), [...]
Nowhere does it says anything about how are these ordered. Maybe
on the DS9K this is decided randomly at program startup.

What does this "ordering" mean? It seems reasonable to *define* the
ordering of bits within a integer object in terms of the values they
represent.

 

[Richard Tobin]

Unless the actual standard differs from n1124.pdf, it says:
If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N?1), [...]
Nowhere does it says anything about how are these ordered. Maybe
on the DS9K this is decided randomly at program startup.

[/QUOTE]

What does this "ordering" mean? It seems reasonable to *define* the
ordering of bits within a integer object in terms of the values they
represent.

You can test it by examining the value after logical operations on
the bits. The C standard defines these to work "as expected", at least
for positive integers.

-- Richard

 

[pete]

And if I'm not wrong, the standard
specifies nothing about the bit order. On a conforming implementation, it
could be sizeof (int) == 2 && CHAR_BIT ==8, and
the first byte of i could contain the first, third, fifth, seventh,
ninth, eleventh, thirteenth, and fifteenth bit in that order, and
the second byte could contain the sixteenth, fourteenth, ..., second bit
in
that order.

Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.

Unless the actual standard differs from n1124.pdf, it says:
If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N?1), [...]
Nowhere does it says anything about how are these ordered. Maybe
on the DS9K this is decided randomly at program startup.

What does this "ordering" mean? It seems reasonable to *define* the
ordering of bits within a integer object in terms of the values they
represent.

However, if an integer type has more than one byte,
there's nothing that says that the two lowest order bits
must be on the same byte.

 

[Robert Gamble]

@gmail.com> ha scritto nel messaggio
And if I'm not wrong, the standard
specifies nothing about the bit order. On a conforming implementation, it
could be sizeof (int) == 2 && CHAR_BIT ==8, and
the first byte of i could contain the first, third, fifth, seventh,
ninth, eleventh, thirteenth, and fifteenth bit in that order, and
the second byte could contain the sixteenth, fourteenth, ..., second bit
in
that order.
Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.
Unless the actual standard differs from n1124.pdf, it says:
If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N?1), [...]
Nowhere does it says anything about how are these ordered.
Let me know when you make it through the second half of that sentence.
The second half of the sentence doesn't say ", with the powers of two
being ordered sequentially throughout each octet".

The full sentence says:
"If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2N 1, so that objects of that type shall be
capable of
representing values from 0 to 2N 1 using a pure binary
representation; this shall be
^^^^^ ^ ^^^^ ^^^^^^
^^^^^^^^^^^^^^
known as the value representation."

Assuming you underlined the "pure binary representation", it +still+
doesn't say the bits have to be in ascending or descending order.

Here is the definition of "pure binary representation" provided by the
Standard as a footnote in 6.2.6.1:
"A positional representation for integers that uses the binary digits
0 and 1, in which the values
represented by successive bits are additive, begin with 1, and are
multiplied by successive integral
powers of 2, except perhaps the bit with the highest position."

Note the "successive" parts. The example presented doesn't fit that
description.

Indeed I suspect we all know some implementations where this isn't the
case.

Then I suspect you would be able to provide at least one such
implementation? How do shifts work on that implementation?

Robert Gamble

 

[Ben Bacarisse]

"Robert Gamble" <[email protected]> ha scritto nel messaggionews:[email protected]...

And if I'm not wrong, the standard
specifies nothing about the bit order. On a conforming implementation, it
could be sizeof (int) == 2 && CHAR_BIT ==8, and
the first byte of i could contain the first, third, fifth, seventh,
ninth, eleventh, thirteenth, and fifteenth bit in that order, and
the second byte could contain the sixteenth, fourteenth, ..., second bit
in
that order.

Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.

Unless the actual standard differs from n1124.pdf, it says:
If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N?1), [...]
Nowhere does it says anything about how are these ordered.

Let me know when you make it through the second half of that sentence.

The second half of the sentence doesn't say ", with the powers of two
being ordered sequentially throughout each octet".

The full sentence says:
"If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2N 1, so that objects of that type shall be
capable of
representing values from 0 to 2N 1 using a pure binary
representation; this shall be
^^^^^ ^ ^^^^ ^^^^^^
^^^^^^^^^^^^^^
known as the value representation."

Assuming you underlined the "pure binary representation", it +still+
doesn't say the bits have to be in ascending or descending order.

Here is the definition of "pure binary representation" provided by the
Standard as a footnote in 6.2.6.1:
"A positional representation for integers that uses the binary digits
0 and 1, in which the values
represented by successive bits are additive, begin with 1, and are
multiplied by successive integral
powers of 2, except perhaps the bit with the highest position."

Note the "successive" parts. The example presented doesn't fit that
description.

Indeed I suspect we all know some implementations where this isn't the
case.

Then I suspect you would be able to provide at least one such
implementation?

I know a machine that used the following byte order for longs: 2143 --
the less significant half word had a lower address than the more
significant half word, but within them the more significant byte
preceded the less significant one. I can't claim that this machine
had a conforming C implementation because it was a long time ago. It
had a C compiler but it pre-dated C90. Do you interpret the standard
to say that it could not have a conforming implementation?

How do shifts work on that implementation?

Shifts worked by doing what was needed to move the bits around in the
right order (although my memory is hazy about this). Shifts are
defined by the arithmetic value of the result, so a conforming
implementation has no choice but to generate code that does whatever
is required. Because this particular machine was micro-coded, I seem
to remember that the team had designed a pair of shift instructions
that did the job. But even if there were only half word shifts
available, the compiler would simply have had to generate two of them
(along with a test and an OR).

I would be surprised if the wording you quote was intended to prevent
such a machine from having a conforming C implementation. I suspect
that the wording is intended to reinforce the idea that the value bits
look consecutive as far as C programs are concerned. In other words,
that shifts and bit-wise logical operations all work together as
defined later on.