473,890 Members | 1,359 Online

# swapping bytes in an integer

If I have a 32 bit unsigned int that is in the wrong byte order, how
can I convert it? For example, if have a number 0x090a0b0c how can I
reverse this to 0x0c0b0a09 ?

Thanks,
-John

May 8 '06
34 13943

<jo**@fcs.uga.e du> wrote in message
news:11******** **************@ j33g2000cwa.goo glegroups.com.. .
Wow! This code is really awesome. I think this is the absolute best
way I have seen yet. I will have to study your code and break it down
to see how it works exaclty. Do you think that it could it be placed
within a #define ?

Yes. Just remember that it's only for 'unsigned long' 's which are 32-bits
in length (i.e., rarely it's non-portable). You'd need a different version
for other unsigned types: short, long long, etc. This method won't work
with signed types.

/* BS for byte-swap */
#define BS(a)
(((a)&0xFF00000 0)>>24)|(((a)&0 xFF0000)>>8)|(( (a)&0xFF00)<<8) |(((a)&0xFF)<<2 4
)

/*...*/
unsigned long a,b;

a=0x090a0b0c;
b=BS(a);
Each 'FF' masks off one of the four respective bytes using the '&' bitwise
and operator. This leaves you with four unsigned long each of which has a
byte to be relocated. The '>>' and '<<' bitshift operators move each byte
to it's new position (within an 'unsigned long'). The '|' bitwise or
operator puts all four unsigned long's, each one with one relocated byte,
back together.

1) four unsigned long's (each 'a')
0x090a0b0
0x090a0b0
0x090a0b0
0x090a0b0

2) and masking, four bytes within unsigned longs
0x09000000
0x000a0000
0x00000b00
0x0000000c

3) shifting, relocated byte within unsigned longs
0x00000009
0x00000a00
0x000b0000
0x0c000000

4) or four together
0x0c0b0a09
This actually optimizes very well with most modern compilers.

It also avoids using byte swapping constructs like arrays or unions which
(in my experience) can cause other programming headaches.
Rod Pemberton
May 10 '06 #21
On 9 May 2006 08:53:26 -0700,
jo**@fcs.uga.ed u <jo**@fcs.uga.e du> wrote
in Msg. <11************ **********@j33g 2000cwa.googleg roups.com>
Wow! This code is really awesome. I think this is the absolute best
way I have seen yet. I will have to study your code and break it down
to see how it works exaclty.
It looks confusing at first, but is simple in reality.
Do you think that it could it be placed
within a #define ?

It could be, but the argument is evaluated four times which will create
trouble if it has side effects. If your macros is called BYTESWAP(a),
then

BYTESWAP(++a) will invoke undefine behavior, and
BYTESWAP(some_f unc(x)) will invoke some_func four times.

Better implement it as an (inline) function.

robert
May 10 '06 #22
<jo**@fcs.uga.e du> wrote in message
news:11******** **************@ j33g2000cwa.goo glegroups.com.. .
Wow! This code is really awesome. I think this is the absolute best
way I have seen yet. I will have to study your code and break it down
to see how it works exaclty. Do you think that it could it be placed
within a #define ?

Yes. Just remember that it's only for 'unsigned long' 's which are 32-bits
in length (i.e., rarely it's non-portable). You'd need a different version
for other unsigned types: short, long long, etc. This method won't work
with signed types.

I think what he means by "rarely it's non-portable" is "it's
non-portable". unsigned long isn't necessary 32 bits; I regularly use
systems on which it's 64 bits.

--
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.
May 10 '06 #23

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...
<jo**@fcs.uga.e du> wrote in message
news:11******** **************@ j33g2000cwa.goo glegroups.com.. .
Wow! This code is really awesome. I think this is the absolute best
way I have seen yet. I will have to study your code and break it down
to see how it works exaclty. Do you think that it could it be placed
within a #define ?

Yes. Just remember that it's only for 'unsigned long' 's which are 32-bits in length (i.e., rarely it's non-portable). You'd need a different version for other unsigned types: short, long long, etc. This method won't work
with signed types.

I think what he means by "rarely it's non-portable" is "it's
non-portable". unsigned long isn't necessary 32 bits; I regularly use
systems on which it's 64 bits.

Just because you use a system regularly doesn't mean that it's a non-rare
system. I wouldn't exactly call the Sun-Blade-100's or Cray's you've used
common... In fact, I wouldn't call any mainframe or mini-frame (including
the ones I've used) common.
Rod Pemberton
May 10 '06 #24
Rod Pemberton wrote:
"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...
<jo**@fcs.ug a.edu> wrote in message

Wow! This code is really awesome. I think this is the absolute best
way I have seen yet. I will have to study your code and break it down
to see how it works exaclty. Do you think that it could it be placed
within a #define ?
Yes. Just remember that it's only for 'unsigned long' 's which are
32-bits
in length (i.e., rarely it's non-portable). You'd need a different
version
for other unsigned types: short, long long, etc. This method won't work
with signed types.

I think what he means by "rarely it's non-portable" is "it's
non-portable". unsigned long isn't necessary 32 bits; I regularly use
systems on which it's 64 bits.

Just because you use a system regularly doesn't mean that it's a non-rare
system. I wouldn't exactly call the Sun-Blade-100's or Cray's you've used
common... In fact, I wouldn't call any mainframe or mini-frame (including
the ones I've used) common.

There are a lot of AMD64 and Intel 64 bit systems out here.

--
Ian Collins.
May 10 '06 #25
"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...
> <jo**@fcs.uga.e du> wrote in message
> news:11******** **************@ j33g2000cwa.goo glegroups.com.. .
>> Wow! This code is really awesome. I think this is the absolute best
>> way I have seen yet. I will have to study your code and break it down
>> to see how it works exaclty. Do you think that it could it be placed
>> within a #define ?
>>
>
> Yes. Just remember that it's only for 'unsigned long' 's which
> are 32-bits in length (i.e., rarely it's non-portable). You'd
> need a different version for other unsigned types: short, long
> long, etc. This method won't work with signed types.

I think what he means by "rarely it's non-portable" is "it's
non-portable". unsigned long isn't necessary 32 bits; I regularly use
systems on which it's 64 bits.

Just because you use a system regularly doesn't mean that it's a non-rare
system. I wouldn't exactly call the Sun-Blade-100's or Cray's you've used
common... In fact, I wouldn't call any mainframe or mini-frame (including
the ones I've used) common.

I didn't say they're non-rare; that's not the point. The point is
that saying "rarely it's non-portable" merely obfuscates the fact that
it's *non-portable*.

64-bit systems are already showing up as home PCs for everyday use,
and they're becoming more and more common.

If you write code that works only on 32-bit systems, it's likely to
work on *most* modern systems. But why waste your time writing code
that works on most systems, when you can write *portable* code with

All the world was not a VAX 25 years ago, and all the world is not a
32-bit x86 today.

--
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.
May 10 '06 #26

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...
"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...
> <jo**@fcs.uga.e du> wrote in message
> news:11******** **************@ j33g2000cwa.goo glegroups.com.. .
>> Wow! This code is really awesome. I think this is the absolute best
>> way I have seen yet. I will have to study your code and break it down >> to see how it works exaclty. Do you think that it could it be placed >> within a #define ?
>>
>
> Yes. Just remember that it's only for 'unsigned long' 's which
> are 32-bits in length (i.e., rarely it's non-portable). You'd
> need a different version for other unsigned types: short, long
> long, etc. This method won't work with signed types.

I think what he means by "rarely it's non-portable" is "it's
non-portable". unsigned long isn't necessary 32 bits; I regularly use
systems on which it's 64 bits.
Just because you use a system regularly doesn't mean that it's a non-rare system. I wouldn't exactly call the Sun-Blade-100's or Cray's you've used common... In fact, I wouldn't call any mainframe or mini-frame (including the ones I've used) common.

I didn't say they're non-rare; that's not the point. The point is
that saying "rarely it's non-portable" merely obfuscates the fact that
it's *non-portable*.

Your perspective is what's incorrect. It is portable. It's portable to any
machine which uses 32-bits for 'unsigned long' which is the extreme majority
of architectures in existence. It's _rare_ for an 'unsigned long' to be any
other size even on 16-bit or 64-bit machines. You've attempted to redefine
portability in terms of a few obscure machines.
64-bit systems are already showing up as home PCs for everyday use,
and they're becoming more and more common.

If you write code that works only on 32-bit systems, it's likely to
work on *most* modern systems. But why waste your time writing code
that works on most systems, when you can write *portable* code with

Since you (claim to) have experience in this area, feel free to post a
portable solution. But, that would violate your personal no-code policy
wouldn't it?
Rod Pemberton
May 11 '06 #27

Rod Pemberton wrote:
"Keith Thompson" <ks***@mib.or g> wrote in message
I didn't say they're non-rare; that's not the point. The point is
that saying "rarely it's non-portable" merely obfuscates the fact that
it's *non-portable*.

Your perspective is what's incorrect. It is portable. It's portable to any
machine which uses 32-bits for 'unsigned long' which is the extreme majority
of architectures in existence. It's _rare_ for an 'unsigned long' to be any
other size even on 16-bit or 64-bit machines. You've attempted to redefine
portability in terms of a few obscure machines.

I think this discussion is overblown. On the one hand, the O/P
specified 32 bit unsigned ints, and the solution you provided is OK
given that spec seems to me. It could add an assert(sizeof(i nt)==4 &&
CHAR_BITS==8) to make sure it isn't misused, but whatever.

On the other hand, the fact that many (at least non-embedded) machines
now use 32 bit ints/longs is not to me relevant. I'd be surprised if
most new desktop/server machines were not 64 bit in the relatively near
future. Writing code, wherever possible, to not care seems entirely
reasonable, unless one is trying to ensure future programming work
upgrading ones source code to be "64 bit safe". This is quite
different (IMHO) than the arguments about whether assuming NULL is all
bits 0 is OK based on the fact that it wasn't in some obsolescent
architectures. I'd go with the pedanticly correct side there too, but
I think it is relatively unlikely that someone will make a new machine
that doesn't treat all bits 0 as NULL. It is a certainty that many new
machines will be released where compilers use long ints that are 64
bits...

-David

May 11 '06 #28
On 2006-05-11, Rod Pemberton <do*********@bi tfoad.cmm> wrote:
Your perspective is what's incorrect. It is portable. It's portable
to any machine which uses 32-bits for 'unsigned long' which is the
extreme majority of architectures in existence. It's _rare_ for an
'unsigned long' to be any other size even on 16-bit or 64-bit
machines. You've attempted to redefine portability in terms of a few
obscure machines.

On what 64-bit machines is unsigned long int a 32-bit type? That's more
rare than for it to be 64 bits.
May 11 '06 #29
"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

[...]
I didn't say they're non-rare; that's not the point. The point is
that saying "rarely it's non-portable" merely obfuscates the fact that
it's *non-portable*.

Your perspective is what's incorrect. It is portable. It's
portable to any machine which uses 32-bits for 'unsigned long' which
is the extreme majority of architectures in existence. It's _rare_
for an 'unsigned long' to be any other size even on 16-bit or 64-bit
machines. You've attempted to redefine portability in terms of a
few obscure machines.

64-bit longs are not rare. 64-bit machines are not obscure. On
64-bit machines, 64-bit longs are much more common than 32-bit longs.
64-bit systems are already showing up as home PCs for everyday use,
and they're becoming more and more common.

If you write code that works only on 32-bit systems, it's likely to
work on *most* modern systems. But why waste your time writing code
that works on most systems, when you can write *portable* code with

Since you (claim to) have experience in this area, feel free to post a
portable solution. But, that would violate your personal no-code policy
wouldn't it?

Stop trolling, and stop making things up.

--
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.
May 11 '06 #30

This thread has been closed and replies have been disabled. Please start a new discussion.