4/5 How do I concatinate two integers together into a long. If I do
something like
(a << 32) | b then this will only work on little endian machines
but not on big endian machines. How do I make concatination
machine dependent?
\_ This will work on both little and big endian machines, if a
contains the high order bits. The question is, where do a
and b come from? If they're being read from a file or some
stream, that's where your endian dependency comes from.
\_ this is bullshit. first of all, on your machie, int's
are probably the same size as long's (this is to the original
poster). To the responder, show me a definition for how
\_ 64-bit Unixes define int as 32-bit & long as 64-bit.
little endian and big endian machines store 64 bit entities.
the way i'd do this is use what he has up there, but at the
beginning of my program, write a routine that asserts that
it's the right way of doing it, and abort() at runtime if
it's not the case.
\_ #ifs
\_ don't you mean independent?
\_ if they are unsigned, can't you do (a*(2^32))+b
\_ This is equivalent to the code above; both work.
or if you need it to work in every situation, you need to look
in limits.h to see the true sizes of an int and a long on your
system, as well as endianness, and work it for the different
situations, have fun.
\_ Well, not true. On a big endian machine, if shift left
a long (which was promoted from a 32-bit int) wouldn't
the lower order bits fall off the left side. A perfect
solution would be to barrel rotate one of the numbers
and OR them together which will guarantee that it will
always work but I know of no barrel rotate function in
the standard C libraries.
say you've promoted ABCD from 16-bits to 32-bits.
- big endian: 0xDCBA0000 << 16 = 0x00000000
- little endian: 0x0000ABCD << 16 = 0xABCD0000
\_ You moron. First of all, that's not promotion, that's
reinterpretation of bits. Second of all, endian-ness
works on the byte level, not the nibble level; so the first
byte of a little endian 0xabcd is 0xcd, not 0xdc. Big
endian systems are intolerant of lazy casting. That's where
your problem lies; it's not with the shift operator. -pld
\_ You moron. You've mixed up big-endian and
little-endian. Plus, endian-ness works on the byte
level, not the nibble level; so the first byte of a
little endian 0xabcd is 0xcd, not 0xdc. This should read
- little endian: 0xCDAB0000 << 16 = 0x0000CDAB
- big endian: 0x0000ABCD << 16 = 0xABCD0000
And both those are the same number. -pld
\_ moron? who's the moron. look in P&H A-48. The lower
order bytes (CDAB) are one the right side for
order bytes (CDAB) are on the right side for
a little endian machine so it should be the other
way around.
\_ Have fun the next time you look at a memory dump -pld
\_ This is incorrect. shift left treats the entire int
as a unit. The high order bits fall off, regardless of
endian-ness. You need to go read K&R again.
\_ Size of int is NBPW*8 in sys/param.h, or simply sizeof(int)*8.
BYTE_ORDER is defined in machine/endian.h. You can also use
ntohl() and others in that file.
\_ but endianness DOESN'T FUCKING MATTER. Try it. Come on
it is a simple c program. Now go compile it on a linuix box.
Now on a sun. Ohh look. See the pretty results. Idiot. |
http://csua.com/feed/