GetByte(x, 3) should return the 3rd byte of the 32 bit integer x. Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks... and using
x&bitmask ?
Any other ideas?
53  8905 
"Floyd" <ja*********@gmail.com> wrote in message
news:f0******************************@localhost.ta lkaboutprogramming.com... GetByte(x, 3) should return the 3rd byte of the 32 bit integer x. Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks... and using
x&bitmask ?
Any other ideas?
There are a couple of others.
But, this group doesnt do home works !!
Post the solution that you have tried. We can comment and suggest different
other approaches.
- Ravi
Floyd wrote: GetByte(x, 3) should return the 3rd byte of the 32 bit integer x.
Allowed operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks... and
using x&bitmask ?
Any other ideas?
Using resources is one thing, asking for the answer to your HW question
straight out is another.
Yes, I keep up with this newsgroup.
--
Jason Whitehurst
<your> cs2110 Head TA ;-)
"Jason Whitehurst" <ja******@cc.gatech.edu> writes: Floyd wrote: GetByte(x, 3) should return the 3rd byte of the 32 bit integer x.
Allowed operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks... and
using x&bitmask ?
Any other ideas?
Using resources is one thing, asking for the answer to your HW question
straight out is another.
Yes, I keep up with this newsgroup.
--
Jason Whitehurst
<your> cs2110 Head TA ;-)
In the immortal words of Homer Simpson:
"D'oh! Stupid poetic justice!"
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Floyd wrote:
GetByte(x, 3) should return the 3rd byte of the 32 bit integer x.
Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks...
and using x&bitmask ?
Any other ideas?
/* BEGIN new.c */
#include <stdio.h>
#include <limits.h>
#define GetByte(x, u) \
((x & UCHAR_MAX << u * CHAR_BIT) >> u * CHAR_BIT)
int main(void)
{
unsigned long hex1, byte;
hex1 = 0x12345678;
printf("Hex1: %#lx\n", hex1);
byte = sizeof hex1;
while (byte-- != 0) {
printf("byte %lu is %#lx\n", byte, GetByte(hex1, byte));
}
return 0;
}
/* END new.c */
--
pete
pete wrote: Floyd wrote:
GetByte(x, 3) should return the 3rd byte of the 32 bit integer x.
Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks...
and using x&bitmask ?
Any other ideas?
[snip]
Why did you solve his homework for him?
Coudn't you read the other answers before throwing out
code like that???
jacob navia wrote: pete wrote: Floyd wrote:
[snip]
Why did you solve his homework for him?
He didn't.
--
"I support the Red Sox and any team that beats the Yankees"
"Any baby snookums can be a Yankee fan, it takes real moral
fiber to be a Red Sox fan"
"I listened to Toronto come back from 3:0 in '42, I plan to
watch Boston come back from 3:0 in 04" Floyd wrote:
GetByte(x, 3) should return the 3rd byte of the 32 bit integer x.
Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks...
and using x&bitmask ?
Any other ideas?
pete wrote:
[code for the rest of us who aren't cheating] [snip]
jacob navia wrote:
Why did you solve his homework for him?
Coudn't you read the other answers before throwing out
code like that???
If he uses code similar to Pete's, he will GetBusted(). This is the
funniest thread I've read here. MPJ
CBFalconer wrote: jacob navia wrote:
pete wrote:
Floyd wrote:
[snip]
Why did you solve his homework for him?
He didn't.
Hint for Jacob: Look at the list of permitted operators ;-)
I really enjoyed Pete's answer: Standard-conforming, short,
elegant, ... and useless for the cheating OP.
Cheers
Michael
Keith Thompson <ks***@mib.org> spoke thus: "Jason Whitehurst" <ja******@cc.gatech.edu> writes:
^^^^^^ (trimmed)
"D'oh! Stupid poetic justice!"
Indeed, although this is my own alma mater we're talking about here...
I just felt the worth of my degree decrease just a tiny bit :)
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Floyd <ja*********@gmail.com> spoke thus: Any other ideas?
Yep - if Jim Greenlee were still teaching 2130, you would be
completely toast. Good luck trying to cheat in 2340...
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
jacob navia wrote:
pete wrote: Floyd wrote:
GetByte(x, 3) should return the 3rd byte of the 32 bit integer x.
Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks...
and using x&bitmask ?
Any other ideas?
[snip]
Why did you solve his homework for him?
I don't know if it's right.
Does
"GetByte(x, 3) should return the 3rd byte of the 32 bit integer x."
mean the value of the third least significant byte of the integer value,
or the value of the third addressable byte of the integer object?
I think "3rd" usually means starting from first,
rather than from zeroeth, like I did before.
/* BEGIN new.c */
#include <stdio.h>
#include <limits.h>
#define GetByte_V(x, u) \
((x & UCHAR_MAX << u * CHAR_BIT - CHAR_BIT) >> u * CHAR_BIT - CHAR_BIT)
#define GetByte_O(x, u) (((unsigned char *)&x)[u - 1])
int main(void)
{
unsigned long hex1, byte;
hex1 = 0x12345678;
printf("\nHex1: %#lx\n", hex1);
byte = 0;
do {
++byte;
printf("byte %lu is %#lx\n", byte, GetByte_V(hex1, byte));
} while (byte != sizeof hex1);
printf("\nHex1: %#lx\n", hex1);
byte = 0;
do {
++byte;
printf("byte %lu is %#lx\n", byte,
(long unsigned)GetByte_O(hex1, byte));
} while (byte != sizeof hex1);
return 0;
}
/* END new.c */
--
pete
"Jason Whitehurst" <ja******@cc.gatech.edu> wrote: Floyd wrote: GetByte(x, 3) should return the 3rd byte of the 32 bit integer x.
Allowed operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks... and
using x&bitmask ?
Any other ideas?
Using resources is one thing, asking for the answer to your HW question
straight out is another.
Yes, I keep up with this newsgroup.
Nice to see swift retribution in action for a change!
Richard
In <f0******************************@localhost.talkab outprogramming.com> "Floyd" <ja*********@gmail.com> writes: GetByte(x, 3) should return the 3rd byte of the 32 bit integer x. Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks... and using
x&bitmask ?
Any other ideas?
Your homework assignment is unclear. What is the 3rd byte of the 32 bit
integer x? Is the counting starting with the most significant byte or
the least significant byte and is the counting 0-based or 1-based?
Because you're an obvious beginner, we shall assume that a byte is 8 bits.
The idea is to bring the byte of interest in the least significant
position of the integer. This is a job for the >> operator, but you'll
have to compute the shift count yourself (even if I wanted to do that
for you, I wouldn't know how, for the reasons explained at the beginning
of my reply).
Once you have the byte there, it is trivial to get rid of all the other
bytes, by masking them away with the bitwise & operator and a suitably
chosen mask (you can trivially figure it out).
The exercise is a bit more interesting if we don't make any assumption
about the byte size. We can get the byte size from <limits.h> as the
macro CHAR_BIT. Once we have it we can build the mask with a loop, but
there are a couple of shortcuts in C: use the macro UCHAR_MAX from the
same header or use the magic expression (unsigned char)(-1).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
In <41***********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes: pete wrote: Floyd wrote:
GetByte(x, 3) should return the 3rd byte of the 32 bit integer x.
Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks...
and using x&bitmask ?
Any other ideas?
[snip]
Why did you solve his homework for him?
Coudn't you read the other answers before throwing out
code like that???
Read Pete's code carefully. No beginner could turn in such a solution
and expect to be happily accepted by the instructor. Unless the
instructor made <limits.h> one of his priorities, of course.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes: #define GetByte(x, u) \
((x & UCHAR_MAX << u * CHAR_BIT) >> u * CHAR_BIT)
Please have the minimal decency not to expose newbies to badly implemented
macros! Both x and u MUST be protected by parentheses in the expression.
Besides, you have chosen the worst algorithm.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Dan Pop wrote: In <f0******************************@localhost.talkab outprogramming.com> "Floyd" <ja*********@gmail.com> writes:
GetByte(x, 3) should return the 3rd byte of the 32 bit integer x. Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks... and using
x&bitmask ?
Any other ideas?
Your homework assignment is unclear. What is the 3rd byte of the 32 bit
integer x? Is the counting starting with the most significant byte or
the least significant byte and is the counting 0-based or 1-based?
Because you're an obvious beginner, we shall assume that a byte is 8 bits.
The idea is to bring the byte of interest in the least significant
position of the integer. This is a job for the >> operator, but you'll
have to compute the shift count yourself (even if I wanted to do that
for you, I wouldn't know how, for the reasons explained at the beginning
of my reply).
Once you have the byte there, it is trivial to get rid of all the other
bytes, by masking them away with the bitwise & operator and a suitably
chosen mask (you can trivially figure it out).
The exercise is a bit more interesting if we don't make any assumption
about the byte size. We can get the byte size from <limits.h> as the
macro CHAR_BIT. Once we have it we can build the mask with a loop, but
there are a couple of shortcuts in C: use the macro UCHAR_MAX from the
same header or use the magic expression (unsigned char)(-1).
It'll have to be UCHAR_MAX, I think, because the list
of permitted operators doesn't include casts.
The permitted operators seem to have been chosen so as
to steer the student away from the byte-extraction solutions
that any normal programmer would use, and towards solutions
that good programmers would avoid. Consider:
- Multiplication is forbidden, making it hard to compute
a shift distance from a byte number.
- The array-indexing operator `[]' is forbidden, so the
shift distance can't even be fetched from a pre-
computed table.
- The prohibition on assignment rules out iterative
methods, and multi-step methods in general.
Fortunately, the problem statement only requires that
the code work for "the 3rd byte;" there is no requirement
on what it should do if the second argument is not 3. This
leads to a simple solution, once the counting ambiguity Dan
points out is resolved. Here's what it might look like
if we assume that the least significant byte is the first,
the next-higher byte is the second, and so forth:
#include <limits.h>
unsigned char GetByte(long x, int ignored) {
return (x & (UCHAR_MAX << (CHAR_BIT + CHAR_BIT)) (CHAR_BIT + CHAR_BIT);
}
Note 1: It's clumsy to mask before shifting rather than
afterward, but if `x' is negative right-shifting it is
problematic.
Note 2: From the problem statement we know that `x' has
exactly 32 bits and that it contains at least three bytes,
hence CHAR_BIT < 11. From the C Standard we know that
CHAR_BIT is at least 8 and that it is a divisor of the
number of bits in `x'. Putting these together, we can
conclude that CHAR_BIT is exactly 8 for the purposes of
this problem, and this permits some simplification:
/* <limits.h> no longer required */
unsigned char GetByte(long x, int ignored) {
return (x & 16711680) >> '\020';
}
No sane programmer would write such crud, but I think
it solves the problem as stated.
-- Er*********@sun.com
Eric Sosman wrote: [...]
#include <limits.h>
unsigned char GetByte(long x, int ignored) {
return (x & (UCHAR_MAX << (CHAR_BIT + CHAR_BIT))
Sorry; I left out a ')' here.
>> (CHAR_BIT + CHAR_BIT);
}
-- Er*********@sun.com
Floyd wrote: GetByte(x, 3) should return the 3rd byte of the 32 bit integer x. Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks... and using
x&bitmask ?
Any other ideas?
By the way, have you considered Endianism into the fray?
Also, what happens when the byte number is 0, 4, 5, 27689?
Is modulo arithmetic performed before accessing the byte?
Is an error returned?
How does one differentiate an returned error value from
a possible value? For example, zero is a possible value,
so is -1, both of which are classic error values.
Hmmm, the assignment needs better definition.
--
Thomas Matthews
C++ newsgroup welcome message: http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq: http://www.comeaucomputing.com/learn/faq/
Other sites: http://www.josuttis.com -- C++ STL Library book "Floyd" wrote:
GetByte(x, 3) should return the 3rd byte of the 32 bit integer x. Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks... and
usingx&bitmask ?
Any other ideas?
Dan Pop wrote
Your homework assignment is unclear. What is the 3rd byte of the 32 bit
integer x? Is the counting starting with the most significant byte or
the least significant byte and is the counting 0-based or 1-based?
Because you're an obvious beginner, we shall assume that a byte is 8 bits.
The idea is to bring the byte of interest in the least significant
position of the integer. This is a job for the >> operator, but you'll
have to compute the shift count yourself (even if I wanted to do that
for you, I wouldn't know how, for the reasons explained at the beginning
of my reply).
Once you have the byte there, it is trivial to get rid of all the other
bytes, by masking them away with the bitwise & operator and a suitably
chosen mask (you can trivially figure it out).
The exercise is a bit more interesting if we don't make any assumption
about the byte size. We can get the byte size from <limits.h> as the
macro CHAR_BIT. Once we have it we can build the mask with a loop, but
there are a couple of shortcuts in C: use the macro UCHAR_MAX from the
same header or use the magic expression (unsigned char)(-1).
Now that everyone's had their fun with Floyd's discomfiture, and the thread
is starting to drift, I wanted to ask a *somewhat* similar question, in that
it involves bit manipulations. I do not, however, have a T.A.
In K&R2 §2.9 appears the following sentence: The bitwise OR operator | is
used to turn bits on:
x=x | SET_ON;
sets to one in x the bits that are set to one in SET_ON.
I've looked in the index and the usual header files, and I find nothing on
SET_ON. I am no longer subject to the admonition to read K&R sequentially,
as I am doing so presently and am past this point. MPJ
Merrill & Michele wrote:
Now that everyone's had their fun with Floyd's discomfiture, and the thread
is starting to drift, I wanted to ask a *somewhat* similar question, inthat
it involves bit manipulations. I do not, however, have a T.A.
In K&R2 §2.9 appears the following sentence: The bitwise OR operator| is
used to turn bits on:
x=x | SET_ON;
sets to one in x the bits that are set to one in SET_ON.
I've looked in the index and the usual header files, and I find nothingon
SET_ON. I am no longer subject to the admonition to read K&R sequentially,
as I am doing so presently and am past this point. MPJ
K&R Classic (I don't have the New Testament) uses the
identifier MASK instead of SET_ON. Neither identifier is
in any way "special" to C, and neither is predefined in a
header or elsewhere. If you want to set the low-order bit
you'd provide a SET_ON or MASK of 1. If you want to set
the three low-order bits you'd use 7:
Original x = 00101010 binary = 42
SET_ON = 00000111 binary = 7
Result = 00101111 binary = 47
Each bit in the final `x' is a one if it was already a one
or if SET_ON's corresponding bit is a one, or is a zero if
both `x' and SET_ON had a zero at that position. Another
(and equivalent) view is that each bit in the final `x' is
a one if SET_ON has a one at that position, or is unchanged
if SET_ON has a zero.
-- Er*********@sun.com
Hi Dan,
Dan Pop wrote: In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
#define GetByte(x, u) \
((x & UCHAR_MAX << u * CHAR_BIT) >> u * CHAR_BIT)
Please have the minimal decency not to expose newbies to badly implemented
macros! Both x and u MUST be protected by parentheses in the expression.
Besides, you have chosen the worst algorithm.
Out of curiosity:
Which, do you think, is the _best_ algorithm for that?
Apart from the fact that I would not want to do this in a macro
in C99 and would not use parentheses so sparingly (macro or not),
I would rather shift and then mask in this case but I do not find
the above solution offending.
Cheers,
Michael
--
E-Mail: Mine is a gmx dot de address.
In article <cl**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote: Keith Thompson <ks***@mib.org> spoke thus:
"Jason Whitehurst" <ja******@cc.gatech.edu> writes: ^^^^^^ (trimmed)
"D'oh! Stupid poetic justice!"
Indeed, although this is my own alma mater we're talking about here...
I just felt the worth of my degree decrease just a tiny bit :)
I would think that seeing a TA catch a student looking for homework
solutions would have the opposite effect...
dave
--
Dave Vandervies dj******@csclub.uwaterloo.caShould anything be taken care of when printf format specifier string has
a ','(comma) in it?
Yes, the comma. It gets printed. --qazmlp and Dave Neary in comp.lang.c
In article <cl**********@news-int2.gatech.edu>, ja******@cc.gatech.edu says... Floyd wrote: GetByte(x, 3) should return the 3rd byte of the 32 bit integer x.
Allowed operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks... and
using x&bitmask ?
Any other ideas?
Using resources is one thing, asking for the answer to your HW question
straight out is another.
Yes, I keep up with this newsgroup.
Good for you. It's a pity this isn't done more widely. It would
really cut down on the number of homework questions asked here.
--
Randy Howard (2reply remove FOOBAR)
In article <41***********************@news.wanadoo.fr>, ja***@jacob.remcomp.fr
says... pete wrote: Floyd wrote:
GetByte(x, 3) should return the 3rd byte of the 32 bit integer x.
Allowed
operators: ! ~ & ^ | + << >> (no assignment!).
Would the easiest way to do this be just creating 4 bit masks...
and using x&bitmask ?
Any other ideas?
[snip]
Why did you solve his homework for him?
Coudn't you read the other answers before throwing out
code like that???
*sigh*
--
Randy Howard (2reply remove FOOBAR)
Thomas Matthews wrote: Hmmm, the assignment needs better definition.
Well, had he posted the entire assignment, your questions would have been
answered. ;-)
--
Jason Whitehurst
Dan Pop wrote: Your homework assignment is unclear.
Well, had he posted the entire assignment, your questions would have been
answered. ;-)
--
Jason Whitehurst
Merrill & Michele wrote: In K&R2 §2.9 appears the following sentence:
The bitwise OR operator | is
used to turn bits on:
x=x | SET_ON;
sets to one in x the bits that are set to one in SET_ON.
I've looked in the index and the usual header files,
and I find nothing on SET_ON.
Their statement is true for all values of SET_ON, if you assume
that the width of SET_ON isn't greater than the width of x.
--
pete
Michael Mair wrote:
Hi Dan,
Dan Pop wrote: In <41***********@mindspring.com>
pete <pf*****@mindspring.com> writes:
#define GetByte(x, u) \
((x & UCHAR_MAX << u * CHAR_BIT) >> u * CHAR_BIT)
Please have the minimal decency not to expose newbies
to badly implemented
macros! Both x and u MUST be protected by parentheses
in the expression.
Besides, you have chosen the worst algorithm.
Out of curiosity:
Which, do you think, is the _best_ algorithm for that?
Apart from the fact that I would not want to do this in a macro
in C99 and would not use parentheses so sparingly (macro or not),
I would rather shift and then mask in this case but I do not find
the above solution offending.
I agree with Dan about the parentheses around macro arguments.
As for the remaining sparsity of parentheses,
I'll admit that I had to look at page 53, to write that.
The algorithm that I chose was just the very first that popped
into my head. I need more practice doing other people's homework.
--
pete
pete wrote: Michael Mair wrote:
Hi Dan,
Dan Pop wrote:
In <41***********@mindspring.com>
pete <pf*****@mindspring.com> writes:
#define GetByte(x, u) \
((x & UCHAR_MAX << u * CHAR_BIT) >> u * CHAR_BIT)
Please have the minimal decency not to expose newbies
to badly implemented
macros! Both x and u MUST be protected by parentheses
in the expression.
Besides, you have chosen the worst algorithm.
Out of curiosity:
Which, do you think, is the _best_ algorithm for that?
Apart from the fact that I would not want to do this in a macro
in C99 and would not use parentheses so sparingly (macro or not),
I would rather shift and then mask in this case but I do not find
the above solution offending.
I agree with Dan about the parentheses around macro arguments.
As for the remaining sparsity of parentheses,
I'll admit that I had to look at page 53, to write that.
The algorithm that I chose was just the very first that popped
into my head. I need more practice doing other people's homework.
*lol* Well, if you really need it, I can give you the more
interesting exercises I wanted my students to do in my C class...
Probably you will provide me with better solutions as my teaching
assistant and I came up with.
I really am just curious what Dan proposes as optimal solution
to the problem.
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.
In <w6********************@comcast.com> "Merrill & Michele" <be********@comcast.net> writes: In K&R2 §2.9 appears the following sentence: The bitwise OR operator | is
used to turn bits on:
x=x | SET_ON;
sets to one in x the bits that are set to one in SET_ON.
I've looked in the index and the usual header files, and I find nothing on
SET_ON.
It's simply a place holder for a programmer-supplied value. The example
*implies* the existence of something like:
#define SET_ON 0xAA /* or whatever */
somewhere upcode.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
In <2t*************@uni-berlin.de> Michael Mair <Mi**********@invalid.invalid> writes: Hi Dan,
Dan Pop wrote: In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
#define GetByte(x, u) \
((x & UCHAR_MAX << u * CHAR_BIT) >> u * CHAR_BIT)
Please have the minimal decency not to expose newbies to badly implemented
macros! Both x and u MUST be protected by parentheses in the expression.
Besides, you have chosen the worst algorithm.
Out of curiosity:
Which, do you think, is the _best_ algorithm for that?
The one I have described upthread, *obviously* ;-)
Apart from the fact that I would not want to do this in a macro
in C99 and would not use parentheses so sparingly (macro or not),
I would rather shift and then mask in this case but I do not find
the above solution offending.
It is offending because it is a lot less readable than the solution
involving one shift and one masking. The correctness of the latter
can be trivially proven, while the above needs to be examined with a lot
more care. Compare:
(((x) & (UCHAR_MAX << (u) * CHAR_BIT)) >> (u) * CHAR_BIT)
(((x) >> (u) * CHAR_BIT) & UCHAR_MAX)
The complexity of an expression increases exponentially with the number
of *combined* shift operators it contains.
The apparent objection that the >> operator has implementation-defined
behaviour if its left operand is signed and negative is moot, because
the bits not well defined by the standard are masked away from the final
result.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
On Wed, 20 Oct 2004 19:19:53 -0400, Jason Whitehurst wrote: Thomas Matthews wrote: Hmmm, the assignment needs better definition.
Well, had he posted the entire assignment, your questions would have been
answered. ;-)
Please post the complete assignment (once it's due date has come and gone
obviously)
--
Nils Petter Vaskinn (n + surname at broadpark dot no)
"They can sense totalitarianism approaching from a distance,
as animals can sense an approaching thunderstorm."
Paul Graham, about Hackers ( http://paulgraham.com/gba.html)
Dan Pop wrote: In <2t*************@uni-berlin.de> Michael Mair <Mi**********@invalid.invalid> writes:
Hi Dan,
Dan Pop wrote:
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
#define GetByte(x, u) \
((x & UCHAR_MAX << u * CHAR_BIT) >> u * CHAR_BIT)
Please have the minimal decency not to expose newbies to badly implemented
macros! Both x and u MUST be protected by parentheses in the expression.
Besides, you have chosen the worst algorithm.
Out of curiosity:
Which, do you think, is the _best_ algorithm for that?
The one I have described upthread, *obviously* ;-)
Ouch, completely escaped me as you usually post concise
code :-) Now that you say it, I find it. I am just not sure
whether I have forgotten it or whether it escaped me due to
my change of the news server... However, thanks for the reply. Apart from the fact that I would not want to do this in a macro
in C99 and would not use parentheses so sparingly (macro or not),
I would rather shift and then mask in this case but I do not find
the above solution offending.
It is offending because it is a lot less readable than the solution
involving one shift and one masking. The correctness of the latter
can be trivially proven, while the above needs to be examined with a lot
more care. Compare:
(((x) & (UCHAR_MAX << (u) * CHAR_BIT)) >> (u) * CHAR_BIT)
(((x) >> (u) * CHAR_BIT) & UCHAR_MAX)
The complexity of an expression increases exponentially with the number
of *combined* shift operators it contains.
The apparent objection that the >> operator has implementation-defined
behaviour if its left operand is signed and negative is moot, because
the bits not well defined by the standard are masked away from the final
result.
Thank you very much!
Now I am reassured; I was not sure whether some very obvious improvement
of the (u) * CHAR_BIT part completely escaped me...
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.
Dan Pop wrote:
.... snip ...
The apparent objection that the >> operator has implementation-
defined behaviour if its left operand is signed and negative is
moot, because the bits not well defined by the standard are
masked away from the final result.
Please point out where, in the standard, this segregation of bits
into classes is defined. A suitable implementation definition
would be "A right shift of a negative value results in zero".
--
"I support the Red Sox and any team that beats the Yankees"
"Any baby snookums can be a Yankee fan, it takes real moral
fiber to be a Red Sox fan" - "I listened to Toronto come back
from 3:0 in '42, I watched Boston come back from 3:0 in '04"
In <41**************@yahoo.com> CBFalconer <cb********@yahoo.com> writes: Dan Pop wrote:
... snip ...
The apparent objection that the >> operator has implementation-
defined behaviour if its left operand is signed and negative is
moot, because the bits not well defined by the standard are
masked away from the final result.
Please point out where, in the standard, this segregation of bits
into classes is defined. A suitable implementation definition
would be "A right shift of a negative value results in zero".
This is at odds with the actual definition of the right shift operator:
5 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.
The only thing the underlined text leaves up to the implementor to
define is the values of the bits filling the vacated bit positions.
They can be all ones or all zeroes (the only cases one will see in real
world implementations) or some arbitrary bit pattern defined by the
implementor. The bits coming from right-shifting E1 have all well
defined values.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Michael Mair <Mi**********@invalid.invalid> wrote in message news:<2t*************@uni-berlin.de>... Hi Dan,
Dan Pop wrote: In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
#define GetByte(x, u) \
((x & UCHAR_MAX << u * CHAR_BIT) >> u * CHAR_BIT)
Please have the minimal decency not to expose newbies to badly implemented
macros! Both x and u MUST be protected by parentheses in the expression.
Besides, you have chosen the worst algorithm.
Apart from the fact that I would not want to do this in a macro
in C99 and would not use parentheses so sparingly (macro or not),
I would rather shift and then mask in this case but I do not find
the above solution offending.
I could bet that the macro will invoke UB if sizeof long > sizeof int,
and also for invokations with u = sizeof int - 1 on most
implementations. But then again, I'm used to being totally wrong about
the simplest of C's rules, so it could be totally the other way
'round.
Mark
Mark Piffer wrote: Michael Mair <Mi**********@invalid.invalid> wrote:
Dan Pop wrote:
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
#define GetByte(x, u) \
((x & UCHAR_MAX << u * CHAR_BIT) >> u * CHAR_BIT)
Please have the minimal decency not to expose newbies to badly implemented
macros! Both x and u MUST be protected by parentheses in the expression.
Besides, you have chosen the worst algorithm.
Apart from the fact that I would not want to do this in a macro
in C99 and would not use parentheses so sparingly (macro or not),
I would rather shift and then mask in this case but I do not find
the above solution offending.
I could bet that the macro will invoke UB if sizeof long > sizeof int,
and also for invokations with u = sizeof int - 1 on most
implementations. But then again, I'm used to being totally wrong about
the simplest of C's rules, so it could be totally the other way
'round.
Umh, are you referring to the given macro or the function/macro I was
describing?
The macro at hand will give you not more problems if
sizeof long > sizeof int.
What sizeof int - 1 has to do with it, I am not sure at all.
Let us, for a moment, assume that we do not use the macro for negative
x and have inserted the parentheses. UCHAR_MAX << u*CHAR_BIT will not
have overlapping non-zero bits with x if u >= sizeof x. As
UCHAR_MAX << u*CHAR_BIT is considered unsigned and a multiple of
exp2(u*CHAR_BIT), it is effectively 0 if we shift "out of" the largest
unsigned type. Now we consider the case u == sizeof x - 1.
What can go wrong? Assume CHAR_BIT==8, sizeof x==2, x=(T*2<<12) +
(U*2<<8) + (V*2<<4) + W, written symbolically as 0xTUVW:
0xff << 1*8 --> 0xff00
0xTUVW & 0xff00 --> 0xTU00
0xTU00 >> 1*8 -->0x$$TU. We assumed nonnegative x -->0xTU
If x was negative, we also could have non-zero nibbles instead
of the $ signs. However, this is only unspecified, not undefined.
Maybe you want to elaborate where you think the UB creeps in.
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.
Dan Pop wrote: In <41**************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Dan Pop wrote:
... snip ...
The apparent objection that the >> operator has implementation-
defined behaviour if its left operand is signed and negative is
moot, because the bits not well defined by the standard are
masked away from the final result.
Please point out where, in the standard, this segregation of bits
into classes is defined. A suitable implementation definition
would be "A right shift of a negative value results in zero".
This is at odds with the actual definition of the right shift operator:
5 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not "the high-order bits of the resulting value," but
"the resulting value, period."
The only thing the underlined text leaves up to the implementor to
define is the values of the bits filling the vacated bit positions.
They can be all ones or all zeroes (the only cases one will see in real
world implementations) or some arbitrary bit pattern defined by the
implementor. The bits coming from right-shifting E1 have all well
defined values.
Well-defined, yes -- but by the implementation, not by
the Standard.
-- Er*********@sun.com
In <cl**********@news1brm.Central.Sun.COM> Eric Sosman <er*********@sun.com> writes: Dan Pop wrote: In <41**************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Dan Pop wrote:
... snip ...
The apparent objection that the >> operator has implementation-
defined behaviour if its left operand is signed and negative is
moot, because the bits not well defined by the standard are
masked away from the final result.
Please point out where, in the standard, this segregation of bits
into classes is defined. A suitable implementation definition
would be "A right shift of a negative value results in zero".
This is at odds with the actual definition of the right shift operator:
5 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not "the high-order bits of the resulting value," but
"the resulting value, period."
The only thing the underlined text leaves up to the implementor to
define is the values of the bits filling the vacated bit positions.
They can be all ones or all zeroes (the only cases one will see in real
world implementations) or some arbitrary bit pattern defined by the
implementor. The bits coming from right-shifting E1 have all well
defined values.
Well-defined, yes -- but by the implementation, not by
the Standard.
Wrong. You have no licence to ignore the first statement of the
paragraph, which is limiting the options of the implementor.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Dan Pop wrote: In <cl**********@news1brm.Central.Sun.COM> Eric Sosman <er*********@sun.com> writes:
This is at odds with the actual definition of the right shift operator:
5 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not "the high-order bits of the resulting value," but
"the resulting value, period."
[...]
Wrong. You have no licence to ignore the first statement of the
paragraph, which is limiting the options of the implementor.
It is a wilful (probably) misreading of the Standard
to maintain that the first sentence invalidates the other
two. Consider the similar construction in 7.12.7.5:
The sqrt functions compute the nonnegative
square root of x. A domain error occurs if
the argument is less than zero.
If the first sentence is taken to be inviolable, as you
suggest in the case of right-shift, then sqrt() must compute
a non-negative square root for *every* argument value, even
negative values. This is, of course, nonsense -- so it
follows that the first sentence *can* be ignored under the
circumstances described in the rest of the paragraph.
"The value is implementation-defined" means what it
says: The implementation has complete freedom to produce
any value it chooses, so long as it documents the choice.
See also 3.17.1 and 3.17.3.
-- Er*********@sun.com
Dan Pop wrote: CBFalconer <cb********@yahoo.com> writes: Dan Pop wrote:... snip ...
The apparent objection that the >> operator has implementation-
defined behaviour if its left operand is signed and negative is
moot, because the bits not well defined by the standard are
masked away from the final result.
Please point out where, in the standard, this segregation of bits
into classes is defined. A suitable implementation definition
would be "A right shift of a negative value results in zero".
This is at odds with the actual definition of the right shift operator:
5 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.
---------------------------------------------------------------
The only thing the underlined text leaves up to the implementor to
define is the values of the bits filling the vacated bit positions.
They can be all ones or all zeroes (the only cases one will see in real
world implementations) or some arbitrary bit pattern defined by the
implementor. The bits coming from right-shifting E1 have all well
defined values.
And the other - underlined portion justifies using my otherwise not
too useful definition, which defines the _value_ of a negative
value of a signed type right-shifted some number of positions.
Your underlined sentence doesn't describe the value of that
entity. The real point is "don't do that".
--
"I support the Red Sox and any team that beats the Yankees"
"Any baby snookums can be a Yankee fan, it takes real moral
fiber to be a Red Sox fan" - "I listened to Toronto come back
from 3:0 in '42, I watched Boston come back from 3:0 in '04"
In <cl**********@news1brm.Central.Sun.COM> Eric Sosman <er*********@sun.com> writes: "The value is implementation-defined" means what it
says: The implementation has complete freedom to produce
any value it chooses, so long as it documents the choice.
See also 3.17.1 and 3.17.3.
Nope. Implementation-defined is a special case of unspecified:
1 implementation-defined behavior
unspecified behavior where each implementation documents how
the choice is made
Also note the enlightening non-normative example:
2 EXAMPLE An example of implementation-defined behavior is the
propagation of the high-order bit when a signed integer is
shifted right.
Then,
1 unspecified behavior
behavior where this International Standard provides two or more
^^^^^^^^^^^
possibilities and imposes no further requirements on which is
^^^^^^^^^^^^^
chosen in any instance
That's precisely what the definition of right shifting negative values
does: it provides a restrictive set of possible results and lets the
implementor describe how the choice is made.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Dan Pop wrote: In <cl**********@news1brm.Central.Sun.COM> Eric Sosman <er*********@sun.com> writes:
"The value is implementation-defined" means what it
says: The implementation has complete freedom to produce
any value it chooses, so long as it documents the choice.
See also 3.17.1 and 3.17.3.
Nope. Implementation-defined is a special case of unspecified:
1 implementation-defined behavior
unspecified behavior where each implementation documents how
the choice is made
That's the definition of implementation-defined
*behavior*, not of an implementation-defined *value*.
The right-shift paragraph says that the *value*, not
the behavior, is implementation-defined -- and once
again, I refer you to the definition of implementation-
defined *value* in 3.17.1:
unspecified value where each implementation
documents how the choice is made
and of unspecified *value* in 3.17.3:
valid value of the relevant type where this
International Standard imposes no requirements
on which value is chosen in any instance
Note the absence of any text similar to that which you
highlighted.
-- Er*********@sun.com
Eric Sosman <er*********@sun.com> writes: Dan Pop wrote: In <41**************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Dan Pop wrote:
... snip ...
The apparent objection that the >> operator has implementation-
defined behaviour if its left operand is signed and negative is
moot, because the bits not well defined by the standard are
masked away from the final result.
Please point out where, in the standard, this segregation of bits
into classes is defined. A suitable implementation definition
would be "A right shift of a negative value results in zero".
This is at odds with the actual definition of the right shift operator:
5 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not "the high-order bits of the resulting value," but
"the resulting value, period."
The only thing the underlined text leaves up to the implementor to
define is the values of the bits filling the vacated bit positions.
They can be all ones or all zeroes (the only cases one will see in real
world implementations) or some arbitrary bit pattern defined by the
implementor. The bits coming from right-shifting E1 have all well
defined values.
Well-defined, yes -- but by the implementation, not by
the Standard.
Before drawing any conclusions, I'd like to suggest a couple of
thought experiments:
Q1. What is the value of the expression '(-3) >> 1'?
Q2. Assuming CHAR_BIT == 8 and sizeof(int) == 4, what is
the value of the expression '((-3) >> 1) & 0x7fffffff'?
Q3. What does the standard say about the values of either
of those expressions?
Both sides have made some good arguments. And there is a sense in
which both points of view could be right - the standard could say what
happens to the bits, but the value still be "implementation-defined".
Ultimately though I think the idea that the bit values are
well-defined even when the left operand is negative falls a little
short. The reason for this is simple: the standard explicitly allows
a signed-magnitude representation scheme for negative integers; if
you think about how right shift would naturally be done for such
numbers, the sign bit wouldn't move, and zeros would be shifted into
the high order (value) bit positions. Clearly the intention would be
that the standard should allow such behavior; and, the resulting bit
values in that case differ from the bit values most of us are used to
for the right shift operation (at least, one of the bit values would
differ).
So, even though a value being "implementation-defined" might not mean
"any value whatsoever", it seems true that different implementations
could yield different bit values after right-shifting and masking.
On Fri, 22 Oct 2004 19:43:50 +0200, Michael Mair
<Mi**********@invalid.invalid> wrote:
Mark Piffer wrote: Michael Mair <Mi**********@invalid.invalid> wrote:
Dan Pop wrote:
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
>#define GetByte(x, u) \
>((x & UCHAR_MAX << u * CHAR_BIT) >> u * CHAR_BIT)
Please have the minimal decency not to expose newbies to badly implemented
macros! Both x and u MUST be protected by parentheses in the expression.
Besides, you have chosen the worst algorithm.
I could bet that the macro will invoke UB if sizeof long > sizeof int,
and also for invokations with u = sizeof int - 1 on most
implementations. But then again, I'm used to being totally wrong about
the simplest of C's rules, so it could be totally the other way
'round.
Umh, are you referring to the given macro or the function/macro I was
describing?
The macro 20 lines above which I quoted.
The macro at hand will give you not more problems if
sizeof long > sizeof int.
What sizeof int - 1 has to do with it, I am not sure at all.
Let us, for a moment, assume that we do not use the macro for negative
x and have inserted the parentheses. UCHAR_MAX << u*CHAR_BIT will not
have overlapping non-zero bits with x if u >= sizeof x. As
UCHAR_MAX << u*CHAR_BIT is considered unsigned and a multiple of
Why is it considered unsigned? I can't find any indication for it
being unsigned.
exp2(u*CHAR_BIT), it is effectively 0 if we shift "out of" the largest
unsigned type. Now we consider the case u == sizeof x - 1.
What can go wrong? Assume CHAR_BIT==8, sizeof x==2, x=(T*2<<12) +
(U*2<<8) + (V*2<<4) + W, written symbolically as 0xTUVW:
0xff << 1*8 --> 0xff00
0xTUVW & 0xff00 --> 0xTU00
0xTU00 >> 1*8 -->0x$$TU. We assumed nonnegative x -->0xTU
If x was negative, we also could have non-zero nibbles instead
of the $ signs. However, this is only unspecified, not undefined.
Maybe you want to elaborate where you think the UB creeps in.
[guess mode]
Lets assume an architecture where sizeof long == 4 and sizeof int ==
2. If you want to extract byte #2 (the byte starting at
2^(2*CHAR_BIT)) of the long argument, your expression will try to
shift the signed integer constant UCHAR_MAX left 2*CHAR_BIT, which is
equal to the width of int, which is UB following 6.5.7/3.
OTOH, if you have sizeof long == sizeof int and both > 1 and want to
extract the highest byte (i.e. sizeof int - 1), you invoke UB because
you shift a positive signed integer so many places left that it can't
be represented in an int, which will cause UB following 6.5.7/4 (last
sentence).
[/guess mode]
Where do I err?
Mark
In <cl**********@news1brm.Central.Sun.COM> Eric Sosman <er*********@sun.com> writes: Dan Pop wrote: In <cl**********@news1brm.Central.Sun.COM> Eric Sosman <er*********@sun.com> writes:
"The value is implementation-defined" means what it
says: The implementation has complete freedom to produce
any value it chooses, so long as it documents the choice.
See also 3.17.1 and 3.17.3.
Nope. Implementation-defined is a special case of unspecified:
1 implementation-defined behavior
unspecified behavior where each implementation documents how
the choice is made
That's the definition of implementation-defined
*behavior*, not of an implementation-defined *value*.
The right-shift paragraph says that the *value*, not
the behavior, is implementation-defined -- and once
again, I refer you to the definition of implementation-
defined *value* in 3.17.1:
unspecified value where each implementation
documents how the choice is made
and of unspecified *value* in 3.17.3:
valid value of the relevant type where this
International Standard imposes no requirements
on which value is chosen in any instance
Note the absence of any text similar to that which you
highlighted.
You have just discovered an inconsistency in the C standard. Note that
the standard's own example of implementation-defined behaviour actually
refers to an implementation-defined value. You won't find the exact
wording of the example anywhere else in the standard.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
"Dan Pop" <Da*****@cern.ch> wrote in message
news:cl**********@sunnews.cern.ch... You have just discovered an inconsistency in the C standard.
*>GASP!<*
My world view is very fragile since I heard that the K&R has an errata
web page. Then there was the whole "all zeroes" is not null fiasco. I
read a post by Dan Pop that WASN'T mean! My head is spinning, and not in
a good (tequila and rum drinks) way!
Oy!
--
Mabden
Dan Pop wrote: The apparent objection that the >> operator has implementation-defined
behaviour if its left operand is signed and negative is moot, because
the bits not well defined by the standard are masked away from the
final result.
If an intermediate result is undefined, then it's all undefined.
The result of a left shift of an int value,
may result in a negative zero.
I believe that can be a trap.
--
pete
pete wrote: Dan Pop wrote:
The apparent objection that the >> operator has implementation-defined
behaviour if its left operand is signed and negative is moot, because
the bits not well defined by the standard are masked away from the
final result.
If an intermediate result is undefined, then it's all undefined.
First, "implementation-defined" is not "undefined."
Second, although the result is implementation-defined
for the case `(negative_int >> n) & UCHAR_MAX' under
discussion, an implementation-defined operand need not
always produce an implementation-defined result. Here
are a few examples of perfectly predictable results from
expressions involving implementation-defined values:
INT_MAX > INT_MIN == 1
(-1 >> 3) * 0 == 0
(-5 / 3) * 3 + (-5 % 3) == 3
(The last example involves implementation-defined values
in C89, but not in C99.)
The result of a left shift of an int value,
may result in a negative zero.
I believe that can be a trap.
Yes, but we were discussing right shifts. Oddly
enough, (-1 << 3) need not produce any value at all;
the behavior is altogether undefined. That's "odd"
in contrast to (-1 >> 3), which does *not* produce
undefined behavior, and whose implemenation-defined
value cannot be a trap value.
-- Er*********@sun.com This thread has been closed and replies have been disabled. Please start a new discussion. | |
