On Friday 28 September 2001 16:42, you wrote:
> On Thursday 27 September 2001 21:29, Wayne E. Van Loon Sr. wrote:
>
> [...copying structs...]
Granted, structs mixing different-sized elements are best avoided.
> A nearly fool-proof method is to use inline functions or macros to access
> elements inside byte arrays. Correctly implemented, this method even
> ensures endian correctness, and usually compiles into virtually no code,
> unless byte order inversion is required. Unless you're going to send data
> between different endian CPUs, you can just make sure that your "encoded"
> endian is the same as the CPU's native endian.
>
> Example:
>
> /*
> * Writes "val" in big endian format into 'buf'.
> * Returns number of bytes written.
> */
> int write_int(char *buf, int val)
> {
> buf[0] = val & 0xff;
> buf[1] = (val>>8) & 0xff;
> buf[2] = (val>>16) & 0xff;
> buf[3] = (val>>24) & 0xff;
> return 4;
> }
>
> Note that for total portability, your should verify that sizeof(int)
> really is 4, as it might be smaller on some systems... (It's not a
> problem if it's bigger - this code will still write a 32 bit int.)
Is there really a situation where simple read/write of int's wouldn't work?
Read/write do byte copies, so there's no problem with alignment in the FIFO
buffer, and the program variables are declared 'int', so they'll be aligned.
Both ends of an RT-FIFO are always going to be accessed by the same hardware
arch (if not the same CPU), so whatever int size and byte order is used on
the RT side will be correct for the user side, right?
My code depends on this (and structs that contain only int members), so I'd
really like to know if I've overlooked something.
<Joe
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
