Jump to content
  • Advertisement
Sign in to follow this  
Alundra

Safe endian macro

This topic is 1263 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

Here what I'm curently using :

#if defined( __m68k__ ) || defined( mc68000 ) || defined( _M_M68K ) || ( defined( __MIPS__ ) && defined( __MISPEB__ ) ) || \
    defined( __ppc__ ) || defined( __POWERPC__ ) || defined( _M_PPC ) || defined( __sparc__ ) || defined( __hppa__ )
    #ifndef ENDIAN_BIG
      #define ENDIAN_BIG
    #endif // ENDIAN_BIG
#else
    #ifndef ENDIAN_LITTLE
      #define ENDIAN_LITTLE
    #endif // ENDIAN_LITTLE
#endif // ENDIAN

Is it safe enough or more check is needed ?

Thanks

 

Share this post


Link to post
Share on other sites
Advertisement

An M68k? Sparc? The freaking HPPA?? What on earth are you coding that requires this level of flexibility? (If it's a generic header for 'everything', stop and do something else that is grounded in reality.)

Even in the multi-system *nix world that tends to develop that type of laundry-list of devices, they are typically added individually as each new system adds support.

I suppose if the original code was starting with a fork of the already cross-platform Frozen Bubbles or something similar, that might make some sense.

Share this post


Link to post
Share on other sites

I changed to that, gives a code lines multiplied by 3 for the platform/architecture/endian detection but surely a lot more safe.

Share this post


Link to post
Share on other sites

This, of course, is going to break if (and when) a new architecture comes out that you haven't already accounted for.

 

How about just storing a number in a short or an int, then checking the value of it's bytes and converting if needed at runtime?  That's similar to the method used by e.g the Quake engine games and it will work irrespective of what future architectures might appear (https://github.com/id-Software/Quake/blob/master/WinQuake/common.c#L1127):

byte swaptest[2] = {1, 0};

if (*(short *) swaptest == 1)
	bigendien = false;
else bigendien = true;

Share this post


Link to post
Share on other sites

I work a lot with embedded, and in particular files and memory dumps from embedded systems. In my experience, it doesn't matter that much if you are running on one or the other, what matters is if you are working with files/data from the other one. Almost all files/dumps/structures/whatever have some magic number header where we just do something like

 

var val = reader.ReadUInt32();

 

if(val == 0xAABBCCDD)
{
  reader.SwitchEndianess = false;
}
else if(val == 0xDDCCBBAA)
{
  reader.SwitchEndianess = true;
}
else

{

 throw new InvalidDataException();

}

 

I suppose it could matter if you try to write a file with a defined byte order though.

 

[Edit]

Also, many processors have runtime switchable endianess, including most ARMs if I'm not mistaken. :)

Edited by DvDmanDT

Share this post


Link to post
Share on other sites

 

This, of course, is going to break if (and when) a new architecture comes out that you haven't already accounted for.

 

How about just storing a number in a short or an int, then checking the value of it's bytes and converting if needed at runtime?  That's similar to the method used by e.g the Quake engine games and it will work irrespective of what future architectures might appear (https://github.com/id-Software/Quake/blob/master/WinQuake/common.c#L1127):

byte swaptest[2] = {1, 0};

if (*(short *) swaptest == 1)
	bigendien = false;
else bigendien = true;

 

Yeah, I vote for this as well. I just run the following at startup and leave it at that:

bool Endian::isSystemLittleEndian()
{
	short number = 0x1;
	char *numPtr = (char*)&number;
	return (numPtr[0] == 1);
}

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!