__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?

__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?

[Christopher Huang-Leaver]

Hello,

This isn't really a compiler bug, but it's something which the manual
doesn't describe too well so I thought I would point this out.

This page of the manual:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros

says this:
"
You should use these macros for testing like this:

          /* Test for a little-endian machine */
          #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__

"
... except you shouldn't !

To test for a little-endian machine you do this;

#include <endian.h>
#if __BYTE_ORDER  == __LITTLE_ENDIAN

I hope this is helpful.  Keep up the great work!

Regards,

Chris


My test:

#include <iostream>
int main()
{
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
std::cout << "small end first\n";
#endif

#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
std::cout << "big end first\n";
#endif

return 0;
}

Output:

small end first
big end first

gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.5
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--disable-altivec --disable-fixed-point --without-ppl --without-cloog
--enable-nls --without-included-gettext --with-system-zlib
--disable-werror --enable-secureplt --enable-multilib
--enable-libmudflap --disable-libssp --enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/python
--enable-checking=release --enable-java-awt=gtk --enable-objc-gc
--enable-languages=c,c++,java,objc,obj-c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.5
p1.2, pie-0.4.5'
Thread model: posix
gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5)


-- 
"They say great science is built on the shoulders of giants - not
here. At Aperture we do all our science from scratch; no hand
holding." - Cave Johnson, CEO Aperture Science.

Follow me on twitter:   @zeonglow

Re: __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?

[Jie Zhang]

On Sat, Aug 6, 2011 at 5:40 PM, Christopher Huang-Leaver
<zeonglow@googlemail.com> wrote:
> Output:
>
> small end first
> big end first
>
> gcc -v
> gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5)
>
I got the same result with g++-4.4 (4.4.6), g++-4.5 (4.5.3) on Debian
testing. But with g++-4.6, I got

small end first

on my x86_64-linux-gnu machine. I think it's a bug, but it has been
fixed in g++-4.6.

Regards,
Jie

Re: __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?

[Jonathan Wakely]

On 6 August 2011 22:40, Christopher Huang-Leaver wrote:
> Hello,
>
> This isn't really a compiler bug, but it's something which the manual
> doesn't describe too well so I thought I would point this out.
>
> This page of the manual:
> http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros

That documentation refers to the latest sources in GCC trunk, not to GCC 4.4

Re: __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?

[Jie Zhang]

On Sat, Aug 6, 2011 at 9:35 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 6 August 2011 22:40, Christopher Huang-Leaver wrote:
>> Hello,
>>
>> This isn't really a compiler bug, but it's something which the manual
>> doesn't describe too well so I thought I would point this out.
>>
>> This page of the manual:
>> http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros
>
> That documentation refers to the latest sources in GCC trunk, not to GCC 4.4
>
Ha, so it's not a bug. It's a new feature, which doesn't exist before 4.6.

Jie