reversing a byte

[Ajay]

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

[CBFalconer]

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.c om, 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/googlegroupsrep ly/>

[Keith Thompson]

CBFalconer <cb********@yah oo.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_Keit h) 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.

[Richard Heathfield]

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)

[Charles Krug]

On 2006-03-24, Keith Thompson <ks***@mib.or g> wrote:

CBFalconer <cb********@yah oo.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.

[jaysome]

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):#de fine CHAR_BIT 8 /* bits per char */

Atmel:
"grep" C:\WINAVR

limits.h(6):#de fine 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

[Vladimir S. Oka]

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