Re: [Pmk-users] Detecting endian ness issues

[Erik de C. L. <eri...@me...>]

On Tue, 25 Jan 2005 18:00:00 +0100
mips <mi...@ne...> wrote:

> Hi Erik,
> well the tutorial is still a work in progress and its content is not 
> reflecting all the capabilities of pmk.
> The pmksetup tool is using the following code since some time now:
> 
> 	if (((((char *)&num)[0]) == 0x41) && ((((char *)&num)[1]) == 0x42) &&
> 	    ((((char *)&num)[2]) == 0x43) && ((((char *)&num)[3]) == 0x44)) {
> 		strlcpy(bo_type, HW_ENDIAN_BIG,
> 				sizeof(bo_type)); /* should not fail */
> 	} else {
> 		if (((((char *)&num)[3]) == 0x41) &&
> 				((((char *)&num)[2]) == 0x42) &&
> 				((((char *)&num)[1]) == 0x43) &&
> 				((((char *)&num)[0]) == 0x44)) {
> 			strlcpy(bo_type, HW_ENDIAN_LITTLE,
> 					sizeof(bo_type)); /* should not fail */
> 		} else {
> 			strlcpy(bo_type, HW_ENDIAN_UNKNOWN,
> 					sizeof(bo_type)); /* should not fail */
> 		}
> 	}
> 
> 
> I suppose this is exactly what you're looking for, isn't it ?

I think you missed the point. The above is a valid test for endian ness,
but I'm more interested in knowing how the detected endinaness is
represented in the resulting config.h file.

If it is represented as the presense or absense of a #define then it is
wrong.


It must represented like this for big endian:

    #define    WORDS_BIGENDIAN     1
    #define    WORDS_LITTLEENDIAN  0

and this for little endian:

    #define    WORDS_BIGENDIAN     0
    #define    WORDS_LITTLEENDIAN  1

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
"I believe C++ instills fear in programmers, fear that the interaction
of some details causes unpredictable results. Its unmanageable complexity
has spawned more fear-preventing tools than any other language, but the
solution _should_ have been to create and use a language that does not
overload the whole goddamn human brain with irrelevant details."
-- Erik Naggum