swapping bytes in an integer

[john]

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

[W Marsh]

On 8 May 2006 14:03:08 -0700, jo**@fcs.uga.edu wrote:

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

The shift operators << and >> shift a value left and right by one bit,
respectively. Shifting by 4 bits will move the value by one hex digit.
You can combine values with the bitwise OR operator, |

[Ian Collins]

jo**@fcs.uga.edu wrote:

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 ?

It my be non-standard, bit if you system has the networking library
function ntohl and you don't require portability, you can use that.

--
Ian Collins.

[Tomás]

Monkey monkey = 0x090a0b0c;

Opps! Should have written:
Monkey monkey;

monkey.four_bytes = 0x090a0b0c;
-Tomás

[W Marsh]

On Mon, 08 May 2006 21:35:03 GMT, "Tomás" <NU**@NULL.NULL> wrote:

Monkey monkey = 0x090a0b0c;

Opps! Should have written:
Monkey monkey;

monkey.four_bytes = 0x090a0b0c;
-Tomás

It makes no difference - we have no idea what Monkey is anyway. It was
probably simpler the first way, we could just assume it was an integer
of some description.

[Keith Thompson]

W Marsh <wa*********@gmail.com> writes:

On 8 May 2006 14:03:08 -0700, jo**@fcs.uga.edu wrote:

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 ?

The shift operators << and >> shift a value left and right by one bit,
respectively. Shifting by 4 bits will move the value by one hex digit.
You can combine values with the bitwise OR operator, |

No, the shift operators shift a value by a specified number of bits.
For example, x<<1 yields x shifted left by one bit, x<<4 yields x
shifted left by 4 bits, and x<<N yields x shifted left by N bits.

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

[Harald van Dijk]

Ian Collins wrote:

jo**@fcs.uga.edu wrote:

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 ?

It my be non-standard, bit if you system has the networking library
function ntohl and you don't require portability, you can use that.

If I understand correctly, ntohl() converts a big endian integer to a
system integer, meaning if system integers are already big endian, it
simply returns whatever you pass it. So it may not be useful even when
it does exist.

Treating the number when it has the wrong byte order as an array of
unsigned char, and manually combining octets (or manually splitting the
number into them, if you have to go the other way), is a more portable
alternative, which if done right should work on any system.

[W Marsh]

On Mon, 08 May 2006 21:53:59 GMT, Keith Thompson <ks***@mib.org>
wrote:

W Marsh <wa*********@gmail.com> writes:

On 8 May 2006 14:03:08 -0700, jo**@fcs.uga.edu wrote:

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 ?

The shift operators << and >> shift a value left and right by one bit,
respectively. Shifting by 4 bits will move the value by one hex digit.
You can combine values with the bitwise OR operator, |

No, the shift operators shift a value by a specified number of bits.
For example, x<<1 yields x shifted left by one bit, x<<4 yields x
shifted left by 4 bits, and x<<N yields x shifted left by N bits.

I meant to write "shift a value left and right through bits", yes.

[Ian Collins]

Harald van Dijk wrote:

Ian Collins wrote:

jo**@fcs.uga.edu wrote:

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 ?

It my be non-standard, bit if you system has the networking library
function ntohl and you don't require portability, you can use that.

If I understand correctly, ntohl() converts a big endian integer to a
system integer, meaning if system integers are already big endian, it
simply returns whatever you pass it. So it may not be useful even when
it does exist.

Yes, you are correct. My advice was wrong.

--
Ian Collins.

[Flash Gordon]

jo**@fcs.uga.edu wrote:

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 ?

Depends on whether you want to convert it in place or not. Anyway, the
simple way to understand is using shift operators >> and << and bitwise
and & for masking.
--
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

[john]

Ian Collins wrote:

jo**@fcs.uga.edu wrote:

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 ?

It my be non-standard, bit if you system has the networking library
function ntohl and you don't require portability, you can use that.

--
Ian Collins.

I just tried ntohl() in my program and this works perfectly. I think I
will use this method. I want to thank everyone who replied for all of
their great ideas! This help is greatly appreciated.

-John

[W Marsh]

On 8 May 2006 15:18:42 -0700, jo**@fcs.uga.edu wrote:

Ian Collins wrote:

jo**@fcs.uga.edu wrote:

> 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 ?
>

It my be non-standard, bit if you system has the networking library
function ntohl and you don't require portability, you can use that.

--
Ian Collins.

I just tried ntohl() in my program and this works perfectly. I think I
will use this method. I want to thank everyone who replied for all of
their great ideas! This help is greatly appreciated.

-John

Then bear in mind that it's not portable, and will have no effect when
compiled for a machine with a different endianess to your own.

[Andrew Poelstra]

On 2006-05-08, W Marsh <wa*********@gmail.com> wrote:

On 8 May 2006 15:18:42 -0700, jo**@fcs.uga.edu wrote:

Ian Collins wrote:

jo**@fcs.uga.edu wrote:
> 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 ?
>
It my be non-standard, bit if you system has the networking library
function ntohl and you don't require portability, you can use that.

--
Ian Collins.

I just tried ntohl() in my program and this works perfectly. I think I
will use this method. I want to thank everyone who replied for all of
their great ideas! This help is greatly appreciated.

-John

Then bear in mind that it's not portable, and will have no effect when
compiled for a machine with a different endianess to your own.

If his code depends on big-endianness, then it doesn't matter that the function
has no effect; it simply means that the machine is already set up correctly
for your functions.

I worded that really poorly, but basically I mean that it is irrelevant what
effect a certain function actually has; only the end result is important.

[W Marsh]

On Mon, 08 May 2006 22:41:34 GMT, Andrew Poelstra
<ap*******@localhost.localdomain> wrote:

On 2006-05-08, W Marsh <wa*********@gmail.com> wrote:

On 8 May 2006 15:18:42 -0700, jo**@fcs.uga.edu wrote:

Ian Collins wrote:
jo**@fcs.uga.edu wrote:
> 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 ?
>
It my be non-standard, bit if you system has the networking library
function ntohl and you don't require portability, you can use that.

--
Ian Collins.

I just tried ntohl() in my program and this works perfectly. I think I
will use this method. I want to thank everyone who replied for all of
their great ideas! This help is greatly appreciated.

-John

Then bear in mind that it's not portable, and will have no effect when
compiled for a machine with a different endianess to your own.

If his code depends on big-endianness, then it doesn't matter that the function
has no effect; it simply means that the machine is already set up correctly
for your functions.

I worded that really poorly, but basically I mean that it is irrelevant what
effect a certain function actually has; only the end result is important.

No - he asked how to swap bytes, not how to manifest a specific
endianess.

If he has data he wants to treat natively, then ntohl is fine.

If he actually wants to swap the bytes of an integer in any case
(implementing a swap opcode in a CPU emulator, for example), he won't
be able to use ntohl.

[EventHelix.com]

> 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 ?

The following article should help:
http://www.eventhelix.com/RealtimeMa...ndOrdering.htm

--
EventStudio System Designer 2.5 - http://www.EventHelix.com/EventStudio
Sequence Diagram Based System Design and Object Interaction Modeling
Tool

[john]

EventHelix.com wrote:

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 ?
The following article should help:
http://www.eventhelix.com/RealtimeMa...ndOrdering.htm

--
EventStudio System Designer 2.5 - http://www.EventHelix.com/EventStudio
Sequence Diagram Based System Design and Object Interaction Modeling
Tool

From this web site...

Routines to convert between big-endian and little-endian formats are
actually quite straight forward. The routines shown below will convert
from both ways, i.e. big-endian to little-endian and back.
Big-endian to Little-endian conversion and back
short convert_short(short in)
{
short out;
char *p_in = (char *) &in;
char *p_out = (char *) &out;
p_out[0] = p_in[1];
p_out[1] = p_in[0];
return out;
}

long convert_long(long in)
{
long out;
char *p_in = (char *) &in;
char *p_out = (char *) &out;
p_out[0] = p_in[3];
p_out[1] = p_in[2];
p_out[2] = p_in[1];
p_out[3] = p_in[0];
return out;
}

[Rod Pemberton]

<jo**@fcs.uga.edu> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...

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 ?

It seems you've found ntohl(), but this is how:

unsigned long a,b;

a=0x090a0b0c;
b=((a&0xFF000000)>>24)|((a&0x00FF0000)>>8)|((a&0x0 000FF00)<<8)|((a&0x000000F
F)<<24);

Of course, you can drop any place holder zeros between 0x and FF.
Rod Pemberton

[Eric Sosman]

jo**@fcs.uga.edu wrote On 05/08/06 18:18,:

Ian Collins wrote:

jo**@fcs.uga.edu wrote:

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 ?

It my be non-standard, bit if you system has the networking library
function ntohl and you don't require portability, you can use that.

--
Ian Collins.

I just tried ntohl() in my program and this works perfectly. I think I
will use this method. I want to thank everyone who replied for all of
their great ideas! This help is greatly appreciated.

<off-topic reason="potential bug">

Be careful: ntohl() does *not* do what you asked.
It converts "network byte order" (Big-Endian) to "host
byte order" (whatever your machine uses). If your
machine uses Big-Endian byte order already, ntohl()
will not swap the bytes: it will do nothing at all.
To put it another way, ntohl() may in fact do what you
want on the machine you're using at the moment, but
will definitely *not* do what you want on all machines.

If you need to swap the bytes unconditionally, no
matter what machine you're using, you'll have to work
a little harder.

</off-topic>

--
Er*********@sun.com

[john]

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 ?

Thanks,
-John

[Keith Thompson]

Eric Sosman <Er*********@sun.com> writes:

jo**@fcs.uga.edu wrote On 05/08/06 18:18,:

Ian Collins wrote:

jo**@fcs.uga.edu wrote:
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 ?

It my be non-standard, bit if you system has the networking library
function ntohl and you don't require portability, you can use that.
I just tried ntohl() in my program and this works perfectly. I think I
will use this method. I want to thank everyone who replied for all of
their great ideas! This help is greatly appreciated.

<off-topic reason="potential bug">

Be careful: ntohl() does *not* do what you asked.
It converts "network byte order" (Big-Endian) to "host
byte order" (whatever your machine uses). If your
machine uses Big-Endian byte order already, ntohl()
will not swap the bytes: it will do nothing at all.
To put it another way, ntohl() may in fact do what you
want on the machine you're using at the moment, but
will definitely *not* do what you want on all machines.

If you need to swap the bytes unconditionally, no
matter what machine you're using, you'll have to work
a little harder.

We're not certain exactly what the OP's requirements are, only what he
stated them to be. He might need a general solution to swapping bytes
(in which case ntohl() won't do it), or it may be that the only time
he'll see a number in the wrong byte order is when it comes from a
network (in which case ntohl() is probably just the thing).
</off-topic>

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

[Rod Pemberton]

<jo**@fcs.uga.edu> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.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)&0xFF000000)>>24)|(((a)&0xFF0000)>>8)|(((a)&0 xFF00)<<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,
jo**@fcs.uga.edu <jo**@fcs.uga.edu> wrote
in Msg. <11**********************@j33g2000cwa.googlegroups .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_func(x)) will invoke some_func four times.

Better implement it as an (inline) function.

robert

[Keith Thompson]

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

<jo**@fcs.uga.edu> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.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_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.

[Rod Pemberton]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

<jo**@fcs.uga.edu> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.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

[Ian Collins]

Rod Pemberton wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

<jo**@fcs.uga.edu> wrote in message
news:11**********************@j33g2000cwa.googl egroups.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.

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

--
Ian Collins.

[Keith Thompson]

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

> <jo**@fcs.uga.edu> wrote in message
> news:11**********************@j33g2000cwa.googlegr oups.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
little additional effort?

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_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.

[Rod Pemberton]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes:
> <jo**@fcs.uga.edu> wrote in message
> news:11**********************@j33g2000cwa.googlegr oups.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
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]

Rod Pemberton wrote:

"Keith Thompson" <ks***@mib.org> 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(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]

On 2006-05-11, Rod Pemberton <do*********@bitfoad.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.

[Keith Thompson]

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.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
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?

Stop trolling, and stop making things up.

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

[Rod Pemberton]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.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
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?

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]

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes: [...]

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

Unjustified insults.

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

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

[Rod Pemberton]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes: [...] > 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.

Unjustified insults.

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]

Rod Pemberton wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
> "Rod Pemberton" <do*********@bitfoad.cmm> writes: feel free to post a portable solution. A good choice would be to the OP's question.

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

[pete]

pete wrote:

Rod Pemberton wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes:
> "Keith Thompson" <ks***@mib.org> wrote in message
> news:ln************@nuthaus.mib.org...
>> "Rod Pemberton" <do*********@bitfoad.cmm> writes:> > feel free to post a portable solution.> > A good choice would be to the OP's question.

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;
}

--
pete