On 18 Oct 2013, at 05:51, Joe Pfeiffer pfeif...@cs.nmsu.edu wrote:
What's wrong with htonl and other similar functions/macroes?
They are pretty good when they fit what you want to do, but there are holes: eg
convert big endian source to host layout. Note that the glibc implementation
uses
On Thu, Oct 17, 2013 at 05:29:33PM +0200, berenger.mo...@neutralite.org wrote:
Speaking about endianness, it really is hard to manage:
void myfunction( ... )
{
#ifdef BIG_ENDIAN
move_bytes_in_a_specific_order
#else
move_bytes_in_the_other_specific_order
#endif
}
Bad way to manage
Le 17.10.2013 18:17, Jonathan Dowland a écrit :
On Thu, Oct 17, 2013 at 05:29:33PM +0200,
berenger.mo...@neutralite.org wrote:
Speaking about endianness, it really is hard to manage:
void myfunction( ... )
{
#ifdef BIG_ENDIAN
move_bytes_in_a_specific_order
#else
On 17 Oct 2013, at 17:47, berenger.mo...@neutralite.org wrote:
I do not understand why?
In both cases with decent compilers it is solved at compile-time, so what
is the problem with preprocessor here? In case BIG_ENDIAN is not defined but
should be?
For the reason I wrote:
otherwise
Jonathan Dowland j...@debian.org writes:
On Thu, Oct 17, 2013 at 05:29:33PM +0200, berenger.mo...@neutralite.org wrote:
Speaking about endianness, it really is hard to manage:
void myfunction( ... )
{
#ifdef BIG_ENDIAN
move_bytes_in_a_specific_order
#else
5 matches
Mail list logo
