By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,712 Members | 1,591 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,712 IT Pros & Developers. It's quick & easy.

reversing a byte

P: n/a
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.

Mar 22 '06 #1
Share this Question
Share on Google+
45 Replies


P: n/a
"Ajay" <aj***********@gmail.com> writes:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.


By writing a function to do it. C would be a good choice of language
for this task.

Good luck.

If you want somebody else to do it for you, I'm sure you can find
someone willing to discuss consulting rates. If this is homework,
please give us your instructor's e-mail address so we can submit our
solutions directly.

And in anticipation of your next followup, please read
<http://cfaj.freeshell.org/google/>.

--
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.
Mar 22 '06 #2

P: n/a
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.


Use a look up table (untested generated code below):

static unsigned char
reverse_byte(unsigned char b)
{
static const unsigned char b_tbl[] = {
0xff, 0xfe, 0xfd, 0xfc, 0xfb, 0xfa, 0xf9, 0xf8,
0xf7, 0xf6, 0xf5, 0xf4, 0xf3, 0xf2, 0xf1, 0xf0,
0xef, 0xee, 0xed, 0xec, 0xeb, 0xea, 0xe9, 0xe8,
0xe7, 0xe6, 0xe5, 0xe4, 0xe3, 0xe2, 0xe1, 0xe0,
0xdf, 0xde, 0xdd, 0xdc, 0xdb, 0xda, 0xd9, 0xd8,
0xd7, 0xd6, 0xd5, 0xd4, 0xd3, 0xd2, 0xd1, 0xd0,
0xcf, 0xce, 0xcd, 0xcc, 0xcb, 0xca, 0xc9, 0xc8,
0xc7, 0xc6, 0xc5, 0xc4, 0xc3, 0xc2, 0xc1, 0xc0,
0xbf, 0xbe, 0xbd, 0xbc, 0xbb, 0xba, 0xb9, 0xb8,
0xb7, 0xb6, 0xb5, 0xb4, 0xb3, 0xb2, 0xb1, 0xb0,
0xaf, 0xae, 0xad, 0xac, 0xab, 0xaa, 0xa9, 0xa8,
0xa7, 0xa6, 0xa5, 0xa4, 0xa3, 0xa2, 0xa1, 0xa0,
0x9f, 0x9e, 0x9d, 0x9c, 0x9b, 0x9a, 0x99, 0x98,
0x97, 0x96, 0x95, 0x94, 0x93, 0x92, 0x91, 0x90,
0x8f, 0x8e, 0x8d, 0x8c, 0x8b, 0x8a, 0x89, 0x88,
0x87, 0x86, 0x85, 0x84, 0x83, 0x82, 0x81, 0x80,
0x7f, 0x7e, 0x7d, 0x7c, 0x7b, 0x7a, 0x79, 0x78,
0x77, 0x76, 0x75, 0x74, 0x73, 0x72, 0x71, 0x70,
0x6f, 0x6e, 0x6d, 0x6c, 0x6b, 0x6a, 0x69, 0x68,
0x67, 0x66, 0x65, 0x64, 0x63, 0x62, 0x61, 0x60,
0x5f, 0x5e, 0x5d, 0x5c, 0x5b, 0x5a, 0x59, 0x58,
0x57, 0x56, 0x55, 0x54, 0x53, 0x52, 0x51, 0x50,
0x4f, 0x4e, 0x4d, 0x4c, 0x4b, 0x4a, 0x49, 0x48,
0x47, 0x46, 0x45, 0x44, 0x43, 0x42, 0x41, 0x40,
0x3f, 0x3e, 0x3d, 0x3c, 0x3b, 0x3a, 0x39, 0x38,
0x37, 0x36, 0x35, 0x34, 0x33, 0x32, 0x31, 0x30,
0x2f, 0x2e, 0x2d, 0x2c, 0x2b, 0x2a, 0x29, 0x28,
0x27, 0x26, 0x25, 0x24, 0x23, 0x22, 0x21, 0x20,
0x1f, 0x1e, 0x1d, 0x1c, 0x1b, 0x1a, 0x19, 0x18,
0x17, 0x16, 0x15, 0x14, 0x13, 0x12, 0x11, 0x10,
0xf, 0xe, 0xd, 0xc, 0xb, 0xa, 0x9, 0x8,
0x7, 0x6, 0x5, 0x4, 0x3, 0x2, 0x1, 0x0
};
return b_tbl[b];
}

-Charlie

Mar 22 '06 #3

P: n/a

Charles Mills wrote:
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.
Use a look up table (untested generated code below):

static unsigned char
reverse_byte(unsigned char b)
{
static const unsigned char b_tbl[] = {

---8<---- sniped totally wrong lookup table ---8<---- };
return b_tbl[b];
}

-Charlie


probably want something like this:
static const unsigned char b_tbl[] = {
0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
...,
0xf, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff
};

you can fill in the blanks.

-Charlie

Mar 22 '06 #4

P: n/a

Charles Mills wrote:
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.
Use a look up table (untested generated code below):

static unsigned char
reverse_byte(unsigned char b)
{
static const unsigned char b_tbl[] = {

---8<---- sniped totally wrong lookup table ---8<---- };
return b_tbl[b];
}

-Charlie


probably want something like this:
static const unsigned char b_tbl[] = {
0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
...,
0xf, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff
};

you can fill in the blanks.

-Charlie

Mar 22 '06 #5

P: n/a
Hi
I give here a piece of code to reverse a byte but iam not sure how good
it is...

unsigned int n=0x01;
unsinged int c=0x00;
int i;
/* b is given byte */
for( i=0; i<8 ;i++)
{
if( b & n) { c=c + 1;}
c<<1;
n<<1;
}
/* the reversed value is stored in c */
--------------------
any one please correct this if any wrong.

Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.


Mar 22 '06 #6

P: n/a

sudharsan wrote:

Don't top-post. I've corrected it here...
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed. Hi
I give here a piece of code to reverse a byte but iam not sure how good
it is...


Why bother posting untested and uncompilable code in response to
someone's question?

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

int main(void)
{
unsigned int n=0x01;
unsinged int c=0x00;
You surely mean:

unsigned int c = 0x00;

unsigned int b = 15;
int i;
/* b is given byte */
for( i=0; i<8 ;i++)
{
if( b & n) { c=c + 1;}
You never declare `b`, let alone assign it value.
c<<1;
n<<1;
These two do precisely nothing (useful);
}
/* the reversed value is stored in c */
printf("b = %d, c = %d\n", b, c);

return 0;
}

So the result is "b = 15, c = 8", `c` being 8 for any `b`.
any one please correct this if any wrong.


I've corrected above it so it will compile and run. Now it's your turn
to correct the logic. You did have an idea how to do this, didn't you?

--
BR, Vladimir

Mar 22 '06 #7

P: n/a
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.


Your question is not very clear. Do you need to reverse the *value* of
the bits in a byte or do you need to reverse their *position*? If you
need to do the former, you can use C's complement operator, (~). If the
latter, you'll need to write a function to do it. If you want it to be
very fast, probably using a 256 byte look-up table is the way to go.

Mar 22 '06 #8

P: n/a
Charles Mills wrote:
Charles Mills wrote:
Ajay wrote:

Hi all,can you please tell the most efficient method to reverse
a byte.Function should return a byte that is reversed.


Use a look up table (untested generated code below):

static unsigned char
reverse_byte(unsigned char b)
{
static const unsigned char b_tbl[] = {

---8<---- sniped totally wrong lookup table ---8<----
};
return b_tbl[b];
}


probably want something like this:
static const unsigned char b_tbl[] = {
0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
...,
0xf, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff
};

you can fill in the blanks.


Works like a charm, NOT, when CHAR_BIT > 8. i.e. document hidden
assumptions. In order of execution:

unsigned char* b_tbl = malloc(1 + UCHAR_MAX);
...
/* code to initialize table, after checking it is non-NULL. */
...
/* code that uses the table */

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Mar 22 '06 #9

P: n/a
sudharsan wrote:
I give here a piece of code to reverse a byte but iam not sure how good
it is...
Well, I'm not commenting on how good it is ... but
a) it's not portable.
b) you could have posted the full function definition
along with the comments about `b` and `c`.
c) it's very poorly indented.
d) your use of whitespace is very strange.
#include <limits.h> /* for CHAR_BIT */

unsigned int reverse_byte(unsigned int b) { unsigned int n=0x01;
unsinged int c=0x00;
int i;
/* b is given byte */
#if 0 for( i=0; i<8 ;i++) #endif

/* Why do you assume a byte is 8 bits? */
for( i=0; i<CHAR_BIT ;i++)
{
if( b & n) { c=c + 1;}
c<<1;
n<<1;
}
/* the reversed value is stored in c */
return c;
}
--------------------
any one please correct this if any wrong.


--
If you're posting through Google read <http://cfaj.freeshell.org/google>
Mar 22 '06 #10

P: n/a
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.


Whence this unhealthy fascination with "most efficient?"
Two minutes ago you asked for the "most efficient" way to find
a substring, now you're asking for the "most efficient" way
to reverse a byte. What's next? The "most efficient" way to
listen to the Emperor Concerto?

For future reference: The C language says nothing about the
amount of time any operation requires, nothing about the amount
of space any executable code occupies, nothing about the power
consumption of the computer running the code, and very little
about the amount of space taken by data objects. Most notions
of "efficiency" incorporate one or more of these measures, so
questions about "efficiency" are usually unanswerable in terms
of C. They may be answerable for a particular implementation of
C on a particular computer, but in that case you should read
the documentation for that implementation or ask your question
in a forum devoted to that implementation; this is the wrong
forum for such questions.

... and if you'll accept a tiny bit of advice from a battle-
scarred veteran: "efficiency" is not the most important attribute
of a program. For example, here is the most "efficient" method
I can think of to solve your byte-reversal problem:

#define REVERSE_BYTE(x) 0

On most machines this will be faster and shorter than almost any
alternative you can come up with, and sometimes it will even give
the right answer. Use it in good health.

--
Eric Sosman
es*****@acm-dot-org.invalid
Mar 22 '06 #11

P: n/a
Hi Eric,Firsto of all thanks for the solution.I understand here what
you want to say but i think in any language(specially in C
language)implementation of algorithm is the most importent thing.this
is not about a simple question like this.But the habbit to think
differently start from this point.All the big companies i have gone for
ask only for efficient and fast solution(with respect to
memory/speed).Anybody can make program..isn't it?bt it depend how you
make it.
I appreciate for your solution but i want to impement the program on my
own.See if you can help me out---
Function prototype shuold be Byte * Reverse(byte)

where byte for example:--- 11100010
output should be ---------- 01000111

Mar 22 '06 #12

P: n/a

Ajay wrote:
Hi Eric,Firsto of all
Quote context! Read:

<http://cfaj.freeshell.org/google/>
<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>
thanks for the solution.I understand here what
you want to say but i think in any language(specially in C
language)implementation of algorithm is the most importent thing.this
is not about a simple question like this.But the habbit to think
differently start from this point.All the big companies i have gone for
ask only for efficient and fast solution(with respect to
memory/speed).Anybody can make program..isn't it?bt it depend how you
make it.
The right approach is:

1. code it in a readable and correct fashion
2. *mesure*
3. if 2. is unsatisfactory, only then improve efficiency

If you don't plan on doing 2., the rules of optimisation are:

1. Don't do it
2. (experts only) Don't do it yet.
I appreciate for your solution but i want to impement the program on my
own.See if you can help me out---
Function prototype shuold be Byte * Reverse(byte)

where byte for example:--- 11100010
output should be ---------- 01000111


By writing it for you? Fat chance!

--
BR, Vladimir

Mar 22 '06 #13

P: n/a
Ajay, le 22/03/2006 a écrit :
[...]
Function prototype shuold be Byte * Reverse(byte)

where byte for example:--- 11100010
output should be ---------- 01000111

several ways here:
http://graphics.stanford.edu/~seande...ReverseObvious

You can choose calculation methods for short code, lookup table method
for fast code.

You can use your own code for a calculation method generating the
lookup table (text) and copy-paste in your final code.

When you have Reverse(), you check Reverse(Reverse()) is identity.

--
Pierre Maurette
Mar 22 '06 #14

P: n/a
On 2006-03-22, Eric Sosman <es*****@acm-dot-org.invalid> wrote:
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.
Whence this unhealthy fascination with "most efficient?"
Two minutes ago you asked for the "most efficient" way to find
a substring, now you're asking for the "most efficient" way
to reverse a byte. What's next? The "most efficient" way to
listen to the Emperor Concerto?


Whereas I agree with your general concensus that an unhealthy
obsession with speed can lead to buggy and convoluted code, it is
also, often the case that the efficient way is also the easiest and
most reliable way in a relatively low level language such as C. The
fact that its a byte being talked about suggests that the reversal is
required in a byte/character orientated arena where efficiency and cpu
cycles do need to be saved. I would not, however, counter sticking
setjmps in or gotos to save a few cycles for non critical function
return replacement : especially if the contents of those functions
were to contain the bulk of the work. Its a % game.

For new programmers, a lot of employers are interested in their
abilities to maximise the performance of a C program while maintaining
readability and maintability. This group can, and does, help in that
education.

For future reference: The C language says nothing about the
amount of time any operation requires, nothing about the amount
of space any executable code occupies, nothing about the power
consumption of the computer running the code, and very little
about the amount of space taken by data objects. Most notions
No, but it is a language picked for its brevity and efficiency : a fair
programmer can almost see the instructions generated and frequently
pick the language for just that feature. There is a reason that Java
or Perl or somesuch is not used for writing 3d modelling engines
expected to render 32 bit graphics in real time.
of "efficiency" incorporate one or more of these measures, so
questions about "efficiency" are usually unanswerable in terms
of C. They may be answerable for a particular implementation of
C on a particular computer, but in that case you should read
the documentation for that implementation or ask your question
in a forum devoted to that implementation; this is the wrong
forum for such questions.
I dont agree. It is a forum for the discussion of the C Language : and
how to do something is as on topic as the result of that procedure. To
suggest that looking for efficiency is not a good thing with a
language like C is suggesting that aiming for structured classes in
Java or C++ is counterproductive to achieving the result.

Efficient code does not have to be nasty code.

... and if you'll accept a tiny bit of advice from a battle-
scarred veteran: "efficiency" is not the most important attribute
of a program. For example, here is the most "efficient" method
I can think of to solve your byte-reversal problem:

#define REVERSE_BYTE(x) 0

On most machines this will be faster and shorter than almost any
alternative you can come up with, and sometimes it will even give
the right answer. Use it in good health.


To the OP : since a byte is only representing (generally..) 8 bits or
256 values then you could look up in an array which you initialise at
program start. Efficient. Else, test bit 0 of source byte, if set then
set bit 0 of destination word. Left shift dest, right shift
source. Repeat 8 times. Look up how to calculate number of bits to be
portable. There may be better ways.

Good luck!

Mar 22 '06 #15

P: n/a
"Ajay" <aj***********@gmail.com> writes:
Hi Eric,Firsto of all thanks for the solution.I understand here what
you want to say but i think in any language(specially in C
language)implementation of algorithm is the most importent thing.this
is not about a simple question like this.But the habbit to think
differently start from this point.All the big companies i have gone for
ask only for efficient and fast solution(with respect to
memory/speed).Anybody can make program..isn't it?bt it depend how you
make it.
I appreciate for your solution but i want to impement the program on my
own.See if you can help me out---
Function prototype shuold be Byte * Reverse(byte)
If you want to implement it on your own, what are you asking us for?
(That's a serious question.)

Your prototype:

Byte *Reverse(byte)

looks odd. There is no predefined type "Byte" or "byte" in C (those
are two different identifiers), and I can't imagine why you'd want to
return a pointer. You probably want

unsigned char reverse(unsigned char *x);
where byte for example:--- 11100010
output should be ---------- 01000111


And please read <http://cfaj.freeshell.org/google/> if you want anyone
to know what you're talking about.

--
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.
Mar 22 '06 #16

P: n/a
Keith Thompson <ks***@mib.org> writes:
[...]
Your prototype:

Byte *Reverse(byte)

looks odd. There is no predefined type "Byte" or "byte" in C (those
are two different identifiers), and I can't imagine why you'd want to
return a pointer. You probably want

unsigned char reverse(unsigned char *x);


Sorry, I *really* didn't want the '*' there. The prototype should be

unsigned char reverse(unsigned char x);

--
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.
Mar 22 '06 #17

P: n/a
"Richard G. Riley" wrote:
On 2006-03-22, Eric Sosman <es*****@acm-dot-org.invalid> wrote:

.... snip ...

For future reference: The C language says nothing about the
amount of time any operation requires, nothing about the amount
of space any executable code occupies, nothing about the power
consumption of the computer running the code, and very little
about the amount of space taken by data objects. Most notions


No, but it is a language picked for its brevity and efficiency :
a fair programmer can almost see the instructions generated and
frequently pick the language for just that feature. There is a
reason that Java or Perl or somesuch is not used for writing 3d
modelling engines expected to render 32 bit graphics in real time.


For a minority, yes. It seems to me that the majority of
programmers today wouldn't recognize a conditional jump, or an
indirect reference, in assembly code if it jumped up and bit them
on the gluteus maximus.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943
Mar 23 '06 #18

P: n/a
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
efficient here is compact code or compact logic not other stuffs..
byte.Function should return a byte that is reversed.


Mar 23 '06 #19

P: n/a
CBFalconer wrote:
Charles Mills wrote:
Charles Mills wrote:
Ajay wrote:

Hi all,can you please tell the most efficient method to reverse
a byte.Function should return a byte that is reversed.

Use a look up table (untested generated code below):

static unsigned char
reverse_byte(unsigned char b)
{
static const unsigned char b_tbl[] = {


---8<---- sniped totally wrong lookup table ---8<----
};
return b_tbl[b];
}


probably want something like this:
static const unsigned char b_tbl[] = {
0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
...,
0xf, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff
};

you can fill in the blanks.

Works like a charm, NOT, when CHAR_BIT > 8. i.e. document hidden
assumptions. In order of execution:


True, but I highly suspect that the OP will ever use an implementation
that defines "CHAR_BIT > 8". Nor would I suspect that most other C
programmers will.

--
jay
Mar 23 '06 #20

P: n/a
jaysome said:
[...] I highly suspect that the OP will ever use an implementation
that defines "CHAR_BIT > 8".
If he sticks with C, it's almost inevitable in the long run.

Nor would I suspect that most other C programmers will.


Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time, and so has anyone else who
has written C for the same chip, and so have lots of other people writing C
for other similar chips, too. And such chips, common a few years ago, are
becoming yet more common all the time.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Mar 23 '06 #21

P: n/a
Richard Heathfield wrote:
jaysome said:

[...] I highly suspect that the OP will ever use an implementation
that defines "CHAR_BIT > 8".

If he sticks with C, it's almost inevitable in the long run.
Nor would I suspect that most other C programmers will.

Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time, and so has anyone else who
has written C for the same chip, and so have lots of other people writing C
for other similar chips, too. And such chips, common a few years ago, are
becoming yet more common all the time.


Okay.

But the fact that you and your co-workers and probably some of your
friends and their friends have used such an implementation does not
hardly qualify for "most" C programmers. After all, you are a revered
mavin here in c.l.c., and you most likely attract others of your type :)

To be sure--a table impementation is fine as long as you understand the
ramifications to portability. And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.

--
jay
Mar 23 '06 #22

P: n/a

jaysome wrote:
Richard Heathfield wrote:
jaysome said:

[...] I highly suspect that the OP will ever use an implementation
that defines "CHAR_BIT > 8".

If he sticks with C, it's almost inevitable in the long run.
Nor would I suspect that most other C programmers will.

Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time, and so has anyone else who
has written C for the same chip, and so have lots of other people writing C
for other similar chips, too. And such chips, common a few years ago, are
becoming yet more common all the time.


Okay.

But the fact that you and your co-workers and probably some of your
friends and their friends have used such an implementation does not
hardly qualify for "most" C programmers. After all, you are a revered
mavin here in c.l.c., and you most likely attract others of your type :)

To be sure--a table impementation is fine as long as you understand the
ramifications to portability.


That's fair enough.
And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.


Can I borrow your crystal ball, please. I'm going to the races. ;-)

How can you be so sure that the next Big Thing in processors won't
have, say, 16 for CHAR_BIT? How long did it take from Intel 4004 to
80386? [non-ASCII native moan: After all, it's high time `char` really
becoming able to represent characters from more than a handful of
languages, without making us jump through hoops.]

Also, it's not necessarilly /today's/ programmers, rather the ones that
will maintain their code, or try to port it to future architectures.

--
BR, Vladimir

--
BR, Vladimir

Mar 23 '06 #23

P: n/a
Vladimir S. Oka wrote:
jaysome wrote:
Richard Heathfield wrote:

jaysome said:

[...] I highly suspect that the OP will ever use an implementation
that defines "CHAR_BIT > 8".
If he sticks with C, it's almost inevitable in the long run.


Nor would I suspect that most other C programmers will.
Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time, and so has anyone else who
has written C for the same chip, and so have lots of other people writing C
for other similar chips, too. And such chips, common a few years ago, are
becoming yet more common all the time.


Okay.

But the fact that you and your co-workers and probably some of your
friends and their friends have used such an implementation does not
hardly qualify for "most" C programmers. After all, you are a revered
mavin here in c.l.c., and you most likely attract others of your type :)

To be sure--a table impementation is fine as long as you understand the
ramifications to portability.

That's fair enough.

And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.

Can I borrow your crystal ball, please. I'm going to the races. ;-)

How can you be so sure that the next Big Thing in processors won't
have, say, 16 for CHAR_BIT?


When, and if, that happens, Microsoft, or some Open Source developers,
will put out an announcement stating that your existing C programs may
be in jeapordy if you have, in arguably a pedantic manner, assumed that
"CHAR_BIT == 8".

(I just searched all 448 source files of one project I work on. Only one
references CHAR_BIT (yippee for me!). I wouldn't be surprised if many of
the regulars here would search their source code and find 0 instances of
use of CHAR_BIT. And I would be eager to hear about how such lack of
usage of CHAR_BIT affects portability.)

My guess--kind of reiterated--is that those who know better will get it
right, and those that don't know better will, well, be just fine.

--
jay
Mar 23 '06 #24

P: n/a
jaysome wrote:
Vladimir S. Oka wrote:
jaysome wrote:
Richard Heathfield wrote:
jaysome said:

>[...] I highly suspect that the OP will ever use an implementation
>that defines "CHAR_BIT > 8".

If he sticks with C, it's almost inevitable in the long run.

>Nor would I suspect that most other C programmers will.

Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time,
<snip>

Okay.

But the fact that you and your co-workers and probably some of your
friends and their friends have used such an implementation does not
hardly qualify for "most" C programmers. After all, you are a revered
mavin here in c.l.c., and you most likely attract others of your type :)

To be sure--a table impementation is fine as long as you understand the
ramifications to portability.
That's fair enough.
And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.


Can I borrow your crystal ball, please. I'm going to the races. ;-)

How can you be so sure that the next Big Thing in processors won't
have, say, 16 for CHAR_BIT?


When, and if, that happens, Microsoft, or some Open Source developers,
will put out an announcement stating that your existing C programs may
be in jeapordy if you have, in arguably a pedantic manner, assumed that
"CHAR_BIT == 8".


You mean like for Y2K problem: s*itloads of money and time will be
spent fixing the avoidable mess?
(I just searched all 448 source files of one project I work on. Only one
references CHAR_BIT (yippee for me!).
Relevant only if your code /relies/ on CHAR_BIT size.
I wouldn't be surprised if many of
the regulars here would search their source code and find 0 instances of
use of CHAR_BIT.
I'd really like that crystal ball of yours...
And I would be eager to hear about how such lack of
usage of CHAR_BIT affects portability.)
Say your code relies on the fact that CHAR_BIT is 8 (or any other
value), and you use a table of 256 values for reversing a `char`
(sounds familiar?). Now, try to re-compile for the architecture with
CHAR_BIT being 9. See the point? I guess even your neat utility that
generates the said table relies on CHAR_BIT being 8, so re-compiling,
and re-running that doesn't help either. Now, where in all those 448
(or 1448, or 11448) source files was that pesky table?!
My guess--kind of reiterated--is that those who know better will get it
right, and those that don't know better will, well, be just fine.


They may be "just fine", I'm worried about someone (possibly me) having
to maintain and port their code, not to mention the possibility of
Ariane, Therac-25 and similar.

--
BR, Vladimir

Mar 23 '06 #25

P: n/a
jaysome wrote:
Vladimir S. Oka wrote:
How can you be so sure that the next Big Thing in processors won't
have, say, 16 for CHAR_BIT?


When, and if, that happens, Microsoft, or some Open Source developers,
will put out an announcement stating that your existing C programs may
be in jeapordy if you have, in arguably a pedantic manner, assumed that
"CHAR_BIT == 8".

(I just searched all 448 source files of one project I work on. Only one
references CHAR_BIT (yippee for me!). I wouldn't be surprised if many of
the regulars here would search their source code and find 0 instances of
use of CHAR_BIT. And I would be eager to hear about how such lack of
usage of CHAR_BIT affects portability.)

My guess--kind of reiterated--is that those who know better will get it
right, and those that don't know better will, well, be just fine.


Nevertheless, all other factor being equal, if there's a fully portable
way to do something, then that is to be preferred over making
assumptions and hard-coding values. That's the point CBFalconer was
making to Charles Mills.

Mar 23 '06 #26

P: n/a
"CBFalconer" wrote:

<snip table driven solution>
Works like a charm, NOT, when CHAR_BIT > 8. i.e. document hidden
assumptions.


Can we back up here?

The OP wanted to get a job, right? He was asked a stupid question, since
there are at least three ways to measure efficiency - footprint, speed,
programmer's time and clarity etc. The OP has two choices, he can say "WTF
do you mean" or he can give the answer this doofus actually wants, a table
look up. Is there even the tiniest doubt that that was the desired answer
to successfully continue the interview? Do you really think this guy
(hopefully from "Human Resources") cares or even knows about peculiar
representations of characters?
Mar 23 '06 #27

P: n/a

osmium wrote:
"CBFalconer" wrote:

<snip table driven solution>
Works like a charm, NOT, when CHAR_BIT > 8. i.e. document hidden
assumptions.


Can we back up here?

The OP wanted to get a job, right? He was asked a stupid question, since
there are at least three ways to measure efficiency - footprint, speed,
programmer's time and clarity etc. The OP has two choices, he can say "WTF
do you mean" or he can give the answer this doofus actually wants, a table
look up. Is there even the tiniest doubt that that was the desired answer
to successfully continue the interview? Do you really think this guy
(hopefully from "Human Resources") cares or even knows about peculiar
representations of characters?


If I was interviewed on C skills by an HR drone, I'd say "thank you"
and leave there and then. If I thought the engineer interviewing me
didn't "care or even know" about such things, I'd run as fast as I
could. If neither was the case, I'd expect to be grilled on just such
an point.

--
BR, Vladimir

Mar 23 '06 #28

P: n/a
Ajay wrote:

Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.


unsigned char bit_rev(unsigned char byte)
{
unsigned hi_mask, lo_mask;

hi_mask = ((unsigned char)-1 >> 1) + 1;
lo_mask = 1;
do {
if (!(byte & hi_mask) != !(byte & lo_mask)) {
byte ^= hi_mask | lo_mask;
}
hi_mask >>= 1;
lo_mask <<= 1;
} while (hi_mask > lo_mask);
return byte;
}

--
pete
Mar 23 '06 #29

P: n/a
pete wrote:
Ajay wrote:

Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.
unsigned char bit_rev(unsigned char byte)
{
unsigned hi_mask, lo_mask;

hi_mask = ((unsigned char)-1 >> 1) + 1;


This is probably a stupid question, but why not simply do hi_mask =
128;?
lo_mask = 1;
do {
if (!(byte & hi_mask) != !(byte & lo_mask)) {
byte ^= hi_mask | lo_mask;
}
hi_mask >>= 1;
lo_mask <<= 1;
} while (hi_mask > lo_mask);
return byte;
}


wow, that took me quite a while to figure out! Just out of curiosity,
is this the "most efficient" method to reverse bits that you know of?

Mar 23 '06 #30

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

santosh wrote:
pete wrote:
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.

unsigned char bit_rev(unsigned char byte)
{
unsigned hi_mask, lo_mask;

hi_mask = ((unsigned char)-1 >> 1) + 1;


This is probably a stupid question, but why not simply do hi_mask =
128;?


Because a char /may/ contain more than 8 bits.

The statement
hi_mask = ((unsigned char)-1 >> 1) + 1;
will result in hi_mask having a char value that only has it's high order
bit on, no matter what size (in bits) a char is.

OTOH,
hi_mask = 128;
is only guaranteed to set /a/ bit (not necessarily the high order bit)
to one.

[snip]
- --

Lew Pitcher, IT Specialist, Corporate Technology Solutions,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEIuJLagVFX4UWr64RAiPqAJ46Gyhsr/6x/nXtNBsc8BGiJmowcACg2EUF
eKgfiLiLY8ze4DrsXA3pT5Q=
=k/wz
-----END PGP SIGNATURE-----
Mar 23 '06 #31

P: n/a
CBFalconer wrote:
Charles Mills wrote:
Charles Mills wrote:
Ajay wrote:

Hi all,can you please tell the most efficient method to reverse
a byte.Function should return a byte that is reversed.

Use a look up table (untested generated code below):

static unsigned char
reverse_byte(unsigned char b)
{
static const unsigned char b_tbl[] = {

---8<---- sniped totally wrong lookup table ---8<----
};
return b_tbl[b];
}


probably want something like this:
static const unsigned char b_tbl[] = {
0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
...,
0xf, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff
};

you can fill in the blanks.


Works like a charm, NOT, when CHAR_BIT > 8. i.e. document hidden
assumptions. In order of execution:

unsigned char* b_tbl = malloc(1 + UCHAR_MAX);
...
/* code to initialize table, after checking it is non-NULL. */
...
/* code that uses the table */


Here is another non protable (but interesting) version based on code
from the book Hackers Delight:

#if CHAR_BIT != 8
# error ---> Code below only works on platforms with CHAR_BIT == 8
#endif
static unsigned char
reverse_byte(unsigned char x)
{
x = (x & 0x55) << 1 | (x >> 1) & 0x55;
x = (x & 0x33) << 2 | (x >> 2) & 0x33;
x = (x & 0x0F) << 4 | (x >> 4) & 0x0F;
return x;
}

Nice divide and conquer approach
0x55 => 01010101
0x33 => 00110011
0x0F => 00001111

-Charlie

Mar 23 '06 #32

P: n/a
Lew Pitcher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

santosh wrote:
pete wrote:
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.
unsigned char bit_rev(unsigned char byte)
{
unsigned hi_mask, lo_mask;

hi_mask = ((unsigned char)-1 >> 1) + 1;


This is probably a stupid question, but why not simply do hi_mask =
128;?


Because a char /may/ contain more than 8 bits.

The statement
hi_mask = ((unsigned char)-1 >> 1) + 1;
will result in hi_mask having a char value that only has it's high order
bit on, no matter what size (in bits) a char is.

OTOH,
hi_mask = 128;
is only guaranteed to set /a/ bit (not necessarily the high order bit)
to one.

[snip]


Thanks.

Mar 23 '06 #33

P: n/a
santosh wrote:
pete wrote:
Ajay wrote:
Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.

unsigned char bit_rev(unsigned char byte)
{
unsigned hi_mask, lo_mask;

hi_mask = ((unsigned char)-1 >> 1) + 1;


This is probably a stupid question, but why not simply do hi_mask =
128;?


Because there might be more than 8 bits in a byte. I used to work on
systems with 16 bit bytes regularly.
lo_mask = 1;
do {
if (!(byte & hi_mask) != !(byte & lo_mask)) {
byte ^= hi_mask | lo_mask;
}
hi_mask >>= 1;
lo_mask <<= 1;
} while (hi_mask > lo_mask);
return byte;
}


wow, that took me quite a while to figure out! Just out of curiosity,
is this the "most efficient" method to reverse bits that you know of?


That depends. On some systems it might be highly inefficient, on other
highly efficient.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Mar 23 '06 #34

P: n/a
pete wrote:
Ajay wrote:

Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.


unsigned char bit_rev(unsigned char byte)
{
unsigned hi_mask, lo_mask;

hi_mask = ((unsigned char)-1 >> 1) + 1;

[snip rest of function definition]

Does this work for one's complement or any other representation of
negative numbers besides two's complement?

Maybe

hi_mask = (UCHAR_MAX + 1) >> 1;

is more portable?

--
If you're posting through Google read <http://cfaj.freeshell.org/google>
Mar 23 '06 #35

P: n/a
santosh wrote:
jaysome wrote:

.... snip ...

(I just searched all 448 source files of one project I work on.
Only one references CHAR_BIT (yippee for me!). I wouldn't be
surprised if many of the regulars here would search their source
code and find 0 instances of use of CHAR_BIT. And I would be
eager to hear about how such lack of usage of CHAR_BIT affects
portability.)

My guess--kind of reiterated--is that those who know better will
get it right, and those that don't know better will, well, be
just fine.


Nevertheless, all other factor being equal, if there's a fully
portable way to do something, then that is to be preferred over
making assumptions and hard-coding values. That's the point
CBFalconer was making to Charles Mills.


Thank you. And, lacking that, document the assumption. E.G:

assert(8 == CHAR_BIT);

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943
Mar 23 '06 #36

P: n/a
Pedro Graca wrote:

pete wrote:
Ajay wrote:

Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.
unsigned char bit_rev(unsigned char byte)
{
unsigned hi_mask, lo_mask;

hi_mask = ((unsigned char)-1 >> 1) + 1;

[snip rest of function definition]

Does this work for one's complement or any other representation of
negative numbers besides two's complement?


Yes.
Maybe

hi_mask = (UCHAR_MAX + 1) >> 1;

is more portable?


Not more portable, but slightly better style, perhaps.

(UCHAR_MAX == (unsigned char)-1) is always true,
regardless of the representation of negative integers.

N869
6.3.1.3 Signed and unsigned integers
[#1] When a value with integer type is converted to another
integer type other than _Bool, if the value can be
represented by the new type, it is unchanged.
[#2] Otherwise, if the new type is unsigned, the value is
converted by repeatedly adding or subtracting one more than
the maximum value that can be represented in the new type
until the value is in the range of the new type.

((unsigned char)-1 == -1 + UCHAR_MAX + 1)
((unsigned char)-1 == UCHAR_MAX )

--
pete
Mar 23 '06 #37

P: n/a
pete wrote:

Pedro Graca wrote:

Maybe

hi_mask = (UCHAR_MAX + 1) >> 1;

is more portable?


Not more portable, but slightly better style, perhaps.


Actually, (UCHAR_MAX + 1) is not portable.

If UCHAR_MAX is equal to UINT_MAX, then
(hi_mask = (UCHAR_MAX + 1) >> 1)
is equal to zero.

--
pete
Mar 23 '06 #38

P: n/a
pete wrote:
Actually, (UCHAR_MAX + 1) is not portable.

If UCHAR_MAX is equal to UINT_MAX, then
(hi_mask = (UCHAR_MAX + 1) >> 1)
is equal to zero.


What about

hi_mask = (UCHAR_MAX >> 1) + 1;
--
If you're posting through Google read <http://cfaj.freeshell.org/google>
Mar 23 '06 #39

P: n/a
Pedro Graca wrote:

pete wrote:
Actually, (UCHAR_MAX + 1) is not portable.

If UCHAR_MAX is equal to UINT_MAX, then
(hi_mask = (UCHAR_MAX + 1) >> 1)
is equal to zero.


What about

hi_mask = (UCHAR_MAX >> 1) + 1;


That's what I thought you had written when I replied
"Not more portable, but slightly better style, perhaps."

--
pete
Mar 23 '06 #40

P: n/a
pete wrote:
pete wrote:
Pedro Graca wrote:

hi_mask = (UCHAR_MAX + 1) >> 1;

is more portable?


Not more portable, but slightly better style, perhaps.


Actually, (UCHAR_MAX + 1) is not portable.

If UCHAR_MAX is equal to UINT_MAX, then
(hi_mask = (UCHAR_MAX + 1) >> 1)
is equal to zero.


and, if UCHAR_MAX is equal to INT_MAX, the expression creates
undefined (or system defined) behaviour, due to the silly way that
integer promotions work. Unsignedness is not preserved.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Mar 24 '06 #41

P: n/a
CBFalconer <cb********@yahoo.com> writes:
pete wrote:
pete wrote:
Pedro Graca wrote:

hi_mask = (UCHAR_MAX + 1) >> 1;

is more portable?

Not more portable, but slightly better style, perhaps.


Actually, (UCHAR_MAX + 1) is not portable.

If UCHAR_MAX is equal to UINT_MAX, then
(hi_mask = (UCHAR_MAX + 1) >> 1)
is equal to zero.


and, if UCHAR_MAX is equal to INT_MAX, the expression creates
undefined (or system defined) behaviour, due to the silly way that
integer promotions work. Unsignedness is not preserved.


It's unlikely that any real implementation would have UCHAR_MAX ==
INT_MAX. CHAR_BIT would have to be at least 15, and int would have to
have exactly CHAR_BIT value bits (plus 1 sign bit), and therefore at
least CHAR_BIT-1 padding bits (since the total number of bits must be
a multiple of CHAR_BIT). Conforming, but silly.

--
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.
Mar 24 '06 #42

P: n/a
jaysome said:
Richard Heathfield wrote:
jaysome said:
Nor would I suspect that most other C programmers will [ever use a
system with CHAR_BIT > 8].

Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time, and so has anyone else
who has written C for the same chip, and so have lots of other people
writing C for other similar chips, too. And such chips, common a few
years ago, are becoming yet more common all the time.


Okay.

But the fact that you and your co-workers and probably some of your
friends and their friends have used such an implementation does not
hardly qualify for "most" C programmers.


Sure, but the kind of chips we're talking about are the very stuff of which
embedded systems are made, and that's where most C work is being done. I
would not be even remotely surprised if CHAR_BIT > 8 systems actually
outnumbered CHAR_BIT = 8 systems.
To be sure--a table impementation is fine as long as you understand the
ramifications to portability.
Absolutely.
And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.


Provided they stay away from the Real World, I agree entirely.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Mar 24 '06 #43

P: n/a
On 2006-03-24, Keith Thompson <ks***@mib.org> wrote:
CBFalconer <cb********@yahoo.com> writes:
pete wrote:
pete wrote:
Pedro Graca wrote:
>
> hi_mask = (UCHAR_MAX + 1) >> 1;
>
> is more portable?

Not more portable, but slightly better style, perhaps.

Actually, (UCHAR_MAX + 1) is not portable.

If UCHAR_MAX is equal to UINT_MAX, then
(hi_mask = (UCHAR_MAX + 1) >> 1)
is equal to zero.


and, if UCHAR_MAX is equal to INT_MAX, the expression creates
undefined (or system defined) behaviour, due to the silly way that
integer promotions work. Unsignedness is not preserved.


It's unlikely that any real implementation would have UCHAR_MAX ==
INT_MAX. CHAR_BIT would have to be at least 15, and int would have to
have exactly CHAR_BIT value bits (plus 1 sign bit), and therefore at
least CHAR_BIT-1 padding bits (since the total number of bits must be
a multiple of CHAR_BIT). Conforming, but silly.


I'm not sure K&R gave any thought to odd ducks like this, any more than
the case where single bits were addressable like the old (iirc)
Borroughs machines.

Mar 25 '06 #44

P: n/a
Richard Heathfield wrote:
jaysome said:

Richard Heathfield wrote:

jaysome said:
Nor would I suspect that most other C programmers will [ever use a
system with CHAR_BIT > 8].
Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time, and so has anyone else
who has written C for the same chip, and so have lots of other people
writing C for other similar chips, too. And such chips, common a few
years ago, are becoming yet more common all the time.


Okay.

But the fact that you and your co-workers and probably some of your
friends and their friends have used such an implementation does not
hardly qualify for "most" C programmers.

Sure, but the kind of chips we're talking about are the very stuff of which
embedded systems are made, and that's where most C work is being done. I
would not be even remotely surprised if CHAR_BIT > 8 systems actually
outnumbered CHAR_BIT = 8 systems.


I'd be very surprised.

Microchip:
"grep" C:\HTSOFT\PIC18\include

limits.h(3):#define CHAR_BIT 8 /* bits per char */

Atmel:
"grep" C:\WINAVR

limits.h(6):#define CHAR_BIT __CHAR_BIT__

__CHAR_BIT__ = 8

Between Microchip and Atmel, that's a lot of chips.
And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.

Provided they stay away from the Real World, I agree entirely.


And I reiterate--most C programmers will be just fine.

When, and if, they ever get to develop with an implementation that
defines CHAR_BIT > 8, and that makes a difference compared to CHAR_BIT =
8, "most" C programmers will directly or indirectly (e.g., via the
testing group) force a result that leads them to conclude that their
assumption about CHAR_BIT = 8 is invalid; subsequently, they would
follow up with a resolution.

That's my Real World, anyways. YMMV.

--
jay
Mar 25 '06 #45

P: n/a
jaysome opined:
Richard Heathfield wrote:
jaysome said:
Richard Heathfield wrote:
jaysome said:
<snip>
And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.
Provided they stay away from the Real World, I agree entirely.


And I reiterate--most C programmers will be just fine.

When, and if, they ever get to develop with an implementation that

^^^^^^^

What about "port old code"?
defines CHAR_BIT > 8, and that makes a difference compared to
CHAR_BIT = 8, "most" C programmers will directly or indirectly (e.g.,
via the testing group) force a result that leads them to conclude
that their assumption about CHAR_BIT = 8 is invalid; subsequently,
they would follow up with a resolution.
Which, in case of "maintain old code" leads to endless hunt for all the
places where integer constant 8 needs to be changed to 13.
That's my Real World, anyways. YMMV.


Not all people are lucky enough to have it easy, and do only
green-field development.

--
BR, Vladimir

He knows not how to know who knows not also how to unknow.
-- Sir Richard Burton

Mar 25 '06 #46

This discussion thread is closed

Replies have been disabled for this discussion.