[GRASS-dev] endian & generic library

Brad Douglas rez at touchofmadness.com
Tue May 9 20:56:09 EDT 2006


On Mon, 2006-05-08 at 23:26 +0100, Glynn Clements wrote:
> Converting an integer to 4 bytes, little-endian:
> 
> 	void serialise_int32_le(unsigned char *buf, long x)
> 	{
> 		int i;
> 		for (i = 0; i < 4; i++)
> 			buf[i] = (x >> i*8) & 0xFF;
> 	}
> 	
> Converting an integer to 4 bytes, big-endian:
> 	
> 	void serialise_int32_be(unsigned char *buf, long x)
> 	{
> 		int i;
> 		for (i = 0; i < 4; i++)
> 			buf[3-i] = (x >> i*8) & 0xFF;
> 	}
> 	
> Converting 4 bytes, little-endian, to an integer;
> 	
> 	long deserialise_int32_le(const unsigned char *buf)
> 	{
> 		long x = 0;
> 		for (i = 0; i < 4; i++)
> 			x |= (buf[i] << i*8);
> 		return x;
> 	}
> 	
> Converting 4 bytes, big-endian, to an integer;
> 	
> 	long deserialise_int32_le(const unsigned char *buf)
> 	{
> 		long x = 0;
> 		for (i = 0; i < 4; i++)
> 			x |= (buf[3-i] << i*8);
> 		return x;
> 	}
> 
> These work regardless of whether the system is big- or little-endian
> or whether x is 32 or 64 bits.

Understood re: endian programming issues.  Should it go into SUBMITTING?

Does it make sense to have these functions, string/debug, and memory
related functions in a separate library?  More trouble than it's worth?

I think we could benefit from having a small library (libcommon?) that
all libraries would link against (where appropriate), rather than having
a number of libraries link to libgis or duplicate efforts where it
really isn't necessary.


-- 
Brad Douglas <rez touchofmadness com>                      KB8UYR
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785




More information about the grass-dev mailing list