swapping bytes in an integer

[Rod Pemberton]

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)&0xFF000000)>>24)|(((a)&0xFF0000)>>8)|(((a)&0xFF00)<<8)|(((a)&0xFF)<<24
)

/*...*/
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

 

[Robert Latest]

On 9 May 2006 08:53:26 -0700,

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_func(x)) will invoke some_func four times.

Better implement it as an (inline) function.

robert

 

[Keith Thompson]

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.

 

[Rod Pemberton]

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

 

[Ian Collins]

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.

 

[Keith Thompson]

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
little additional effort?

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

 

[Rod Pemberton]

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
little additional effort?

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

 

[David Resnick]

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(int)==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

 

[Jordan Abel]

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.

 

[Keith Thompson]

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.

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.

 

[Rod Pemberton]

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.


Stop trolling, and stop making things up.

Unjustified insults. If you wish to claim that my code is non-portable,
that's fine. But, at least back up your argument by teaching the OP, me,
and everyone else here how to write portable code by actually posting some
that you wrote.


Rod Pemberton

 

[Keith Thompson]

Unjustified insults.

Not at all. You claim I have a "personal no-code policy". I do not.
You made it up.

 

[Rod Pemberton]

Not at all. You claim I have a "personal no-code policy". I do not.
You made it up.

Really? (I have yet to see one since I've been posting here, since I've been
reading here-alot longer, in Google's indexing-even longer...) So perhaps
your policy is implicit instead of explicit. Put some money where your
mouth is: post some code that you wrote. A good choice would be to the OP's
question.


Rod Pemberton

 

[pete]

To use OP's example value portably,
the type has to be at least as large as long.

/* BEGIN new.c */

#include <stdio.h>

long unsigned rev_uint_bytes(long unsigned number);

int main(void)
{
long unsigned x = 0x0c0b0a09;

printf("x is %lx\n", x);
x = rev_uint_bytes(x);
printf("x with the byte order reversed is %lx\n", x);
return 0;
}

long unsigned rev_uint_bytes(long unsigned number)
{
unsigned char *lower, *upper, swap;

lower = (unsigned char*)&number;
upper = lower + sizeof number;
do {
swap = *lower;
*lower++ = *upper;
*upper-- = swap;
} while(upper > lower);
return number;
}

/* END new.c */

 

[pete]

To use OP's example value portably,
the type has to be at least as large as long.

long unsigned rev_uint_bytes(long unsigned number)
{
unsigned char *lower, *upper, swap;

lower = (unsigned char*)&number;
upper = lower + sizeof number;
do {
swap = *lower;
*lower++ = *upper;
*upper-- = swap;
} while(upper > lower);
return number;
}

I screwed that up.
It should be:

long unsigned rev_uint_bytes(long unsigned number)
{
unsigned char *lower, *upper, swap;

lower = (unsigned char*)&number;
upper = lower + sizeof number - 1;
while(upper > lower) {
swap = *lower;
*lower++ = *upper;
*upper-- = swap;
}
return number;
}