Test you C skills !!!!!!!

[aarklon]

Hi all,

I was going through the book Test your C skills by "Test your C
skills" by Yashavant p. Kanetkar,ISBN 81-7029-801-6

I have got the following doubts ,questions...???

1)On shifting, the bits from the left are rotated and brought to the
right and accomodated where there is empty space on the right.

the reader is asked to tell if this statement is true or not???

The answer is given as false, when i discussed with my friends they
told me that correct answer is implementation dependent.

well what is the correct answer...???

2) To free() we only pass the pointer to the block of memory which we
want to deallocate.Then how does free() know how many bytes it should
deallocate()...???

the answer is given as follows:-

In most implementations of malloc() the number of bytes allocated
is stored adjacent to the allocated block.Hence it is simple for
free() to know how many bytes to deallocate().

To what extent this answer is true...???

 

[Richard Heathfield]

(e-mail address removed) said:

Hi all,

I was going through the book Test your C skills by "Test your C
skills" by Yashavant p. Kanetkar,ISBN 81-7029-801-6

I have got the following doubts ,questions...???

1)On shifting, the bits from the left are rotated and brought to the
right and accomodated where there is empty space on the right.

the reader is asked to tell if this statement is true or not???

The answer is given as false, when i discussed with my friends they
told me that correct answer is implementation dependent.

well what is the correct answer...???

It's false for one and a half reasons. Firstly, no rotation occurs.
Secondly, even if it did, the statement as given would apply only to left
shifts.

2) To free() we only pass the pointer to the block of memory which we
want to deallocate.Then how does free() know how many bytes it should
deallocate()...???

the answer is given as follows:-

In most implementations of malloc() the number of bytes allocated
is stored adjacent to the allocated block.Hence it is simple for
free() to know how many bytes to deallocate().

To what extent this answer is true...???

The Standard doesn't say. It is entirely up to the implementation, and it
is certainly true that some implementations do this in the described
manner.

 

[vippstar]

2) To free() we only pass the pointer to the block of memory which we
want to deallocate.Then how does free() know how many bytes it should
deallocate()...???

To free() you can pass the return value of malloc(), realloc() and
calloc().
May that be a unique pointer, a valid pointer or NULL.

 

[Philip Potter]

Hi all,

I was going through the book Test your C skills by "Test your C
skills" by Yashavant p. Kanetkar,ISBN 81-7029-801-6

I have got the following doubts ,questions...???

1)On shifting, the bits from the left are rotated and brought to the
right and accomodated where there is empty space on the right.

the reader is asked to tell if this statement is true or not???

The answer is given as false, when i discussed with my friends they
told me that correct answer is implementation dependent.

well what is the correct answer...???

The book is correct, your friends are not.

n1256 6.5.7p4 says:
"The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
bits are filled with zeros."
p5 says:
"The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has
an unsigned type or if E1 has a signed type and a nonnegative value, the
value of the result is the integral part of the quotient of E1 / 2^{E2}.
If E1 has a signed type and a negative value, the resulting value is
implementation-defined."

(Where x^{y} is x to the power of y)

In theory, the implementation could define right-shifting of negative
numbers to be a rotate-right operation instead. But it couldn't do the
same of positive numbers, so the principle of least surprise demands
that an implementation shift in zeroes or sign-extend (logical or
arithmetic right shift respectively).

This leads me to an interesting question: Is right-shifting defined at
all on plain char?

 

[Mark Bluemel]

Hi all,

I was going through the book Test your C skills by "Test your C
skills" by Yashavant p. Kanetkar,ISBN 81-7029-801-6

I have got the following doubts ,questions...???

1)On shifting, the bits from the left are rotated and brought to the
right and accomodated where there is empty space on the right.

the reader is asked to tell if this statement is true or not???

The answer is given as false, when i discussed with my friends they
told me that correct answer is implementation dependent.

well what is the correct answer...???

Did you look to find out what the standard says?
Or a standard reference text?
If so, what didn't you understand about the answer?
If not, why not? Do you trust uninformed chatter with your friends
more than the standard or a good text book?

2) To free() we only pass the pointer to the block of memory which we
want to deallocate.Then how does free() know how many bytes it should
deallocate()...???

the answer is given as follows:-

In most implementations of malloc() the number of bytes allocated
is stored adjacent to the allocated block.Hence it is simple for
free() to know how many bytes to deallocate().

To what extent this answer is true...???

All that is required is that free knows how many bytes to deallocate,
the way it knows that is up to the implementer. They may use the
strategy you describe, but there are others. A C programmer has no
need, generally, to know what strategy is used.

 

[Ben Bacarisse]

This leads me to an interesting question: Is right-shifting defined at
all on plain char?

The operands are promoted so in one sense the answer is no (because
the shift happens on the promoted value) and in another sense yes
because the meaning will depend on what char promotes to.

 

[Ben Pfaff]

To free() you can pass the return value of malloc(), realloc() and
calloc().
May that be a unique pointer, a valid pointer or NULL.

This is all true, but it's hard to see how it bears on the OP's
question.

 

[pete]

Hi all,

I was going through the book Test your C skills by "Test your C
skills" by Yashavant p. Kanetkar,ISBN 81-7029-801-6

I have got the following doubts ,questions...???

1)On shifting, the bits from the left are rotated and brought to the
right and accomodated where there is empty space on the right.

the reader is asked to tell if this statement is true or not???

The answer is given as false, when i discussed with my friends they
told me that correct answer is implementation dependent.

well what is the correct answer...???

Your friends don't know what they're talking about.

2) To free() we only pass the pointer to the block of memory which we
want to deallocate.Then how does free() know how many bytes it should
deallocate()...???

the answer is given as follows:-

In most implementations of malloc() the number of bytes allocated
is stored adjacent to the allocated block.Hence it is simple for
free() to know how many bytes to deallocate().

To what extent this answer is true...???

I don't care.
Either you know what your target platform is, or you don't.

If you don't,
then it doesn't make sense to write code as though you do.

 

[Old Wolf]

(e-mail address removed) said:



It's false for one and a half reasons. Firstly, no rotation occurs.
Secondly, even if it did, the statement as given would apply only to left
shifts.

I assume he is talking about left shifts. A left shift
could be implemented as a rotation (shifting a 0 off the
left requires a 0 to enter at the right; shifting a 1
off the left causes undefined behaviour).

 

[Jack Klein]

I assume he is talking about left shifts. A left shift
could be implemented as a rotation (shifting a 0 off the
left requires a 0 to enter at the right; shifting a 1
off the left causes undefined behaviour).

Not on unsigned types, it couldn't.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Richard Heathfield]

Old Wolf said:

I assume he is talking about left shifts.
Okay.

A left shift
could be implemented as a rotation (shifting a 0 off the
left requires a 0 to enter at the right; shifting a 1
off the left causes undefined behaviour).

Shifting a 1 off the left does not necessarily cause undefined behaviour.
The behaviour for unsigned types, and for signed types with non-negative
values, is defined in 6.5.7(4):

"The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
are filled with zeros. If E1 has an unsigned type, the value of the result
is E1 x 2 [to the power of] E2, reduced modulo one more than the maximum
value representable in the result type. If E1 has a signed type and
nonnegative value, and E1 x 2 [to the power of] E2 is representable in the
result type, then that is the resulting value; otherwise, the behavior is
undefined."

 

[Philip Potter]

Old Wolf said:

A left shift
could be implemented as a rotation (shifting a 0 off the
left requires a 0 to enter at the right; shifting a 1
off the left causes undefined behaviour).

Shifting a 1 off the left does not necessarily cause undefined behaviour.
The behaviour for unsigned types, and for signed types with non-negative
values, is defined in 6.5.7(4):

"The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
are filled with zeros. If E1 has an unsigned type, the value of the result
is E1 x 2 [to the power of] E2, reduced modulo one more than the maximum
value representable in the result type. If E1 has a signed type and
nonnegative value, and E1 x 2 [to the power of] E2 is representable in the
result type, then that is the resulting value; otherwise, the behavior is
undefined."

But how could you ever shift a one out of the left of a non-negative
integer? My reading of n1256 6.2.6.2p2 is that since the value bits of a
signed type are defined in terms of the corresponding value bits of an
unsigned type, they must be the N rightmost bits, and therefore the sign
bit must be the leftmost (non-padding) bit. Therefore a non-negative
integer must necessarily have leftmost bit zero.

Shifting a 1 off the left of a signed type therefore implies
left-shifting a negative number, and undefined behaviour.

Of course shifting a 1 off the left of an unsigned type is perfectly
well-defined.

 

[Richard Heathfield]

Philip Potter said:

But how could you ever shift a one out of the left of a non-negative
integer?

Oh yeah, you'd probably need a paint spray, wouldn't you? And you'd have to
wait until the processor's back was turned...

 

[Philip Potter]

Philip Potter said:



Oh yeah, you'd probably need a paint spray, wouldn't you? And you'd have to
wait until the processor's back was turned...

That strikes me as highly shifty behaviour.

(What are you talking about?)

 

[karthikbalaguru]

Hi all,

I was going through the book Test your C skills by "Test your C
skills" by Yashavant p. Kanetkar,ISBN 81-7029-801-6

I have got the following doubts ,questions...???

1)On shifting, the bits from the left are rotated and brought to the
right and accomodated where there is empty space on the right.

the reader is asked to tell if this statement is true or not???

The answer is given as false, when i discussed with my friends they
told me that correct answer is implementation dependent.

well what is the correct answer...???

It is correct for left shifts.
Signed Number bit shifting and Unsigned Number bit shifting should
be handled with card.

2) To free() we only pass the pointer to the block of memory which we
want to deallocate.Then how does free() know how many bytes it should
deallocate()...???

the answer is given as follows:-

In most implementations of malloc() the number of bytes allocated
is stored adjacent to the allocated block.Hence it is simple for
free() to know how many bytes to deallocate().

To what extent this answer is true...???

Implementation dependent.

Karthik Balaguru

 

[Mark Bluemel]

It is correct for left shifts.

Nope. Given that several people have given the right answer, why add a
wrong one?

Signed Number bit shifting and Unsigned Number bit shifting should
be handled with card.

What on earth do you mean by that?

 

[Ben Bacarisse]

It is correct for left shifts.

What is the "it"? The OP gives two answers (both wrong) but which one
are saying is correct for left shifts? Shifts don't rotate and left
shifts are either undefined or well-defined arithmetically -- never
implementation defined.

 

[pete]

Old Wolf said:

I assume he is talking about left shifts.
Okay.

A left shift
could be implemented as a rotation (shifting a 0 off the
left requires a 0 to enter at the right; shifting a 1
off the left causes undefined behaviour).

Shifting a 1 off the left does not necessarily
cause undefined behaviour.
The behaviour for unsigned types,
and for signed types with non-negative
values, is defined in 6.5.7(4):

"The result of E1 << E2 is E1 left-shifted E2 bit positions;
vacated bits are filled with zeros.
If E1 has an unsigned type, the value of the result
is E1 x 2 [to the power of] E2,
reduced modulo one more than the maximum
value representable in the result type.
If E1 has a signed type and
nonnegative value, and E1 x 2 [to the power of]
E2 is representable in the result type,
then that is the resulting value; otherwise, the behavior is
undefined."

C89 doesn't say what happens if E1 is a signed type
for a left shift..

ISO/IEC 9899: 1990
6.3.7 Bitwise shift operators

The result of E1 << E2 is E1 left-shifted E2 bit positions;
vacated bits are filled with zeros.
If E1 has an unsigned type,
the value of the result is E1 multiplied by the quantity,
2 raised to the power E2, reduced modulo ULONG_MAX+1
if E1 has type unsigned long, UINT_MAX+1 otherwise.
(The constants ULONG_MAX and UINT_MAX
are defined in the header <limits.h>.)

The result of E1 >> E2 is E1 right-shifted E2 bit positions.