Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Determining endianess at compile time
172 views
Skip to first unread message
Juha Nieminen
May 15, 2015, 2:44:29 AM5/15/15
to
Is it possible to determine endianess at compile time (in C++14)?
At runtime it can be determined, for example, like this:
bool isLittleEndianSystem()
{
unsigned value = 1;
unsigned char* ptr = (unsigned char*)&value;
return *ptr == 1;
}
Changing that to a constexpr function, however, doesn't seem so trivial
(unless I'm missing something obvious). Any ideas?
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
At runtime it can be determined, for example, like this:
bool isLittleEndianSystem()
{
unsigned value = 1;
unsigned char* ptr = (unsigned char*)&value;
return *ptr == 1;
}
Changing that to a constexpr function, however, doesn't seem so trivial
(unless I'm missing something obvious). Any ideas?
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Öö Tiib
May 15, 2015, 4:50:17 AM5/15/15
to
On Friday, 15 May 2015 09:44:29 UTC+3, Juha Nieminen wrote:
> Is it possible to determine endianess at compile time (in C++14)?
>
> At runtime it can be determined, for example, like this:
>
> bool isLittleEndianSystem()
> {
> unsigned value = 1;
> unsigned char* ptr = (unsigned char*)&value;
> return *ptr == 1;
> }
>
> Changing that to a constexpr function, however, doesn't seem so trivial
> (unless I'm missing something obvious). Any ideas?
Answer depends on if your question is of academical or of practical nature.
> Is it possible to determine endianess at compile time (in C++14)?
>
> At runtime it can be determined, for example, like this:
>
> bool isLittleEndianSystem()
> {
> unsigned value = 1;
> unsigned char* ptr = (unsigned char*)&value;
> return *ptr == 1;
> }
>
> Changing that to a constexpr function, however, doesn't seem so trivial
> (unless I'm missing something obvious). Any ideas?
In theory with standard C++ it is impossible:
* There are no macros that help neither in C nor C++ ( and even not in POSIX).
* 'std::numeric_limits' specify nothing about order of bits.
* All the type punning through union or casts (that you need for manufacturing
such check) are clearly listed as things that do *not* produce constant
expressions by standard.
In practice it is easy:
Download boost and <boost/endian.hpp> figures it out compile time for fairly
decent list of platforms.
http://www.boost.org/doc/libs/1_58_0/boost/detail/endian.hpp
Scott Lurndal
May 15, 2015, 10:32:13 AM5/15/15
to
Juha Nieminen <nos...@thanks.invalid> writes:
>Is it possible to determine endianess at compile time (in C++14)?
on linux it is, regardless of the C++ version. Several of our
>Is it possible to determine endianess at compile time (in C++14)?
C++ projects need to run on both LE and BE systems, we have
this in a common header file then use the appropriate accessors
in the code. Yes, it works with C as well.
#include <endian.h>
#ifndef __BYTE_ORDER
#if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
#define __BYTE_ORDER __BIG_ENDIAN
#elif !defined(__BIG_ENDIAN) && defined(__LITTLE_ENDIAN)
#define __BYTE_ORDER __LITTLE_ENDIAN
#define __BIG_ENDIAN 4321
#elif !defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
#define __BIG_ENDIAN 4321
#define __BYTE_ORDER __BIG_ENDIAN
#else
#error Unable to determine Endian mode
#endif
#endif
#if !defined(htobe16)
# if __BYTE_ORDER == __LITTLE_ENDIAN
# define htobe16(x) __bswap_16 (x)
# define htole16(x) (x)
# define be16toh(x) __bswap_16 (x)
# define le16toh(x) (x)
# define htobe32(x) __bswap_32 (x)
# define htole32(x) (x)
# define be32toh(x) __bswap_32 (x)
# define le32toh(x) (x)
# define htobe64(x) __bswap_64 (x)
# define htole64(x) (x)
# define be64toh(x) __bswap_64 (x)
# define le64toh(x) (x)
# else
# define htobe16(x) (x)
# define htole16(x) __bswap_16 (x)
# define be16toh(x) (x)
# define le16toh(x) __bswap_16 (x)
# define htobe32(x) (x)
# define htole32(x) __bswap_32 (x)
# define be32toh(x) (x)
# define le32toh(x) __bswap_32 (x)
# define htobe64(x) (x)
# define htole64(x) __bswap_64 (x)
# define be64toh(x) (x)
# define le64toh(x) __bswap_64 (x)
# endif
#endif
Juha Nieminen
May 15, 2015, 11:42:33 AM5/15/15
to
Öö Tiib <oot...@hot.ee> wrote:
> Answer depends on if your question is of academical or of practical nature.
I am making a library that handles binary data on a rather low level,
> Answer depends on if your question is of academical or of practical nature.
and would require different code depending on endianness. However,
since it's *highly* unlikely that the library will ever be used on
a big-endian system (it's proprietary code), I'm too lazy to add support.
However, rather than just malfunctioning if that ever happens, I would
prefer if a compiler error would be issued instead. static_assert would
be perfect for this purpose, if it were possible to determine endianness
at compile time. It's preferable for the library to fail to compile than
to silently handle the data in an erroneous manner.
(Adding support for the other endianness would be a lot more work than
to write a simple static_assert.)
red floyd
May 15, 2015, 1:05:57 PM5/15/15
to
On 5/15/2015 7:32 AM, Scott Lurndal wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>> Is it possible to determine endianess at compile time (in C++14)?
>
> on linux it is, regardless of the C++ version. Several of our
> C++ projects need to run on both LE and BE systems, we have
> this in a common header file then use the appropriate accessors
> in the code. Yes, it works with C as well.
>
> #include <endian.h>
> #ifndef __BYTE_ORDER
> #if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
> #define __BYTE_ORDER __BIG_ENDIAN
> #elif !defined(__BIG_ENDIAN) && defined(__LITTLE_ENDIAN)
> #define __BYTE_ORDER __LITTLE_ENDIAN
> #define __BIG_ENDIAN 4321
> #elif !defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
> #define __BIG_ENDIAN 4321
> #define __BYTE_ORDER __BIG_ENDIAN
> #else
> #error Unable to determine Endian mode
> #endif
> #endif
Just to be snarky, where's PDP Endian -- 2143?
> Juha Nieminen <nos...@thanks.invalid> writes:
>> Is it possible to determine endianess at compile time (in C++14)?
>
> on linux it is, regardless of the C++ version. Several of our
> C++ projects need to run on both LE and BE systems, we have
> this in a common header file then use the appropriate accessors
> in the code. Yes, it works with C as well.
>
> #include <endian.h>
> #ifndef __BYTE_ORDER
> #if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
> #define __BYTE_ORDER __BIG_ENDIAN
> #elif !defined(__BIG_ENDIAN) && defined(__LITTLE_ENDIAN)
> #define __BYTE_ORDER __LITTLE_ENDIAN
> #define __BIG_ENDIAN 4321
> #elif !defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
> #define __BIG_ENDIAN 4321
> #define __BYTE_ORDER __BIG_ENDIAN
> #else
> #error Unable to determine Endian mode
> #endif
> #endif
Richard
May 15, 2015, 1:21:52 PM5/15/15
to
[Please do not mail me a copy of your followup]
sl...@pacbell.net spake the secret code
<Ern5x.269$zW5...@fx12.iad> thusly:
>#include <endian.h>
>#ifndef __BYTE_ORDER
> #if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
> #define __BYTE_ORDER __BIG_ENDIAN
All identifiers beginning with __ are reserved for the implementation;
you should never define these yourself.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
sl...@pacbell.net spake the secret code
<Ern5x.269$zW5...@fx12.iad> thusly:
>#include <endian.h>
>#ifndef __BYTE_ORDER
> #if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
> #define __BYTE_ORDER __BIG_ENDIAN
you should never define these yourself.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Victor Bazarov
May 15, 2015, 1:57:09 PM5/15/15
to
On 5/15/2015 1:21 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> sl...@pacbell.net spake the secret code
> <Ern5x.269$zW5...@fx12.iad> thusly:
>
>> #include <endian.h>
>> #ifndef __BYTE_ORDER
>> #if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
>> #define __BYTE_ORDER __BIG_ENDIAN
>
> All identifiers beginning with __ are reserved for the implementation;
> you should never define these yourself.
Nit-pick: not only beginning with __, but *containing* __. As to the
> [Please do not mail me a copy of your followup]
>
> sl...@pacbell.net spake the secret code
> <Ern5x.269$zW5...@fx12.iad> thusly:
>
>> #include <endian.h>
>> #ifndef __BYTE_ORDER
>> #if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
>> #define __BYTE_ORDER __BIG_ENDIAN
>
> All identifiers beginning with __ are reserved for the implementation;
> you should never define these yourself.
beginning, it's the "an underscore and a capital letter", according to
the Holy Standard.
V
--
I do not respond to top-posted replies, please don't ask
Message has been deleted
Scott Lurndal
May 15, 2015, 4:15:30 PM5/15/15
to
legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><Ern5x.269$zW5...@fx12.iad> thusly:
>
>>#include <endian.h>
>>#ifndef __BYTE_ORDER
>> #if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
>> #define __BYTE_ORDER __BIG_ENDIAN
>
>All identifiers beginning with __ are reserved for the implementation;
>you should never define these yourself.
I'm quite well aware of that, having spent a decade on various
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><Ern5x.269$zW5...@fx12.iad> thusly:
>
>>#include <endian.h>
>>#ifndef __BYTE_ORDER
>> #if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
>> #define __BYTE_ORDER __BIG_ENDIAN
>
>All identifiers beginning with __ are reserved for the implementation;
>you should never define these yourself.
standards committees (88open, UI, TOG).
Regardless, you'll find it quite common in the real world, particularly
amongst operating system programmers, who consider themselves part of
the implementation.
Richard
May 15, 2015, 4:34:35 PM5/15/15
to
<mts5x.984$695...@fx31.iad> thusly:
>Regardless, you'll find it quite common in the real world, particularly
>amongst operating system programmers, who consider themselves part of
>the implementation.
Just because it's commonplace, doesn't mean it's a good idea.
One should always strive to produce code that works by design instead
of working by accident.
Unless you are the implementor of the compiler or the standard
library, there is never any need to introduce identifiers that begin
with __.
The presented code was suggested as a way for an application
programmer to determine endianness at compile time. In such code,
using identifiers beginning with __ is simply a bad idea and in
violation of the standard, whether is compiles or not.
>Regardless, you'll find it quite common in the real world, particularly
>amongst operating system programmers, who consider themselves part of
>the implementation.
One should always strive to produce code that works by design instead
of working by accident.
Unless you are the implementor of the compiler or the standard
library, there is never any need to introduce identifiers that begin
with __.
The presented code was suggested as a way for an application
programmer to determine endianness at compile time. In such code,
using identifiers beginning with __ is simply a bad idea and in
violation of the standard, whether is compiles or not.
Richard
May 15, 2015, 4:37:20 PM5/15/15
to
[Please do not mail me a copy of your followup]
(Richard) legaliz...@mail.xmission.com spake the secret code
<mj59v7$fg1$1...@news.xmission.com> thusly:
>All identifiers beginning with __ are reserved for the implementation;
>you should never define these yourself.
"Certain sets of names and function signatures are always reserved to
the implementation:"
-- Each name that contains a double underscore _ _ or begins with an
underscore followed by an uppercase letter (2.12) is reserved to the
implementation for any use.
-- Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.
Robert Wessel
May 15, 2015, 5:57:44 PM5/15/15
to
On Fri, 15 May 2015 06:44:20 +0000 (UTC), Juha Nieminen
<nos...@thanks.invalid> wrote:
>Is it possible to determine endianess at compile time (in C++14)?
>
>At runtime it can be determined, for example, like this:
>
> bool isLittleEndianSystem()
> {
> unsigned value = 1;
> unsigned char* ptr = (unsigned char*)&value;
> return *ptr == 1;
> }
>
>Changing that to a constexpr function, however, doesn't seem so trivial
>(unless I'm missing something obvious). Any ideas?
To pick a nit, that won't work if chars are the same size as int on
<nos...@thanks.invalid> wrote:
>Is it possible to determine endianess at compile time (in C++14)?
>
>At runtime it can be determined, for example, like this:
>
> bool isLittleEndianSystem()
> {
> unsigned value = 1;
> unsigned char* ptr = (unsigned char*)&value;
> return *ptr == 1;
> }
>
>Changing that to a constexpr function, however, doesn't seem so trivial
>(unless I'm missing something obvious). Any ideas?
the implementation.
As for constexprs, I think you're going to have issues with anything
that requires a reinterpret_cast.
OTOH, I know of no good way to check at compile time.
Message has been deleted
Robert Wessel
May 16, 2015, 3:13:47 AM5/16/15
to
On 15 May 2015 22:12:39 GMT, r...@zedat.fu-berlin.de (Stefan Ram)
wrote:
>r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>GNU C has »endian.h«, some systems have »sys/param.h«.
>
> The following code might not always yield the intended
> outcome as others have pointed out that some parts
> are not portable or well-defined, but it /is/ compiled
> with »constexpr«.
>
>#include <iostream>
>#include <ostream>
>
>constexpr bool endian()
>{ using bytes = struct { char a; };
> using overlay = union { int i; bytes b; };
> return overlay{ 1 }.b.a; }
>
>int main()
>{ ::std::cout << "endian()" << " = " << endian() << '\n'; }
>
> One could add security / sanity checks, such as statically
> asserting that sizeof( char)< sizeof( int ) or that one of
> the bytes is one and all preceding bytes are zero.
Does the rule that a constexpr cannot have "An lvalue-to-rvalue
implicit conversion applied to a non-active member of a union or its
subobject" apply here?
wrote:
>r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>Öö Tiib <oot...@hot.ee> writes:
>>>In practice it is easy:
>>>Download boost and <boost/endian.hpp> figures it out compile time for fairly
>>>decent list of platforms.
>>Another means might be the Autoconf AC_C_BIGENDIAN feature.
>>>In practice it is easy:
>>>Download boost and <boost/endian.hpp> figures it out compile time for fairly
>>>decent list of platforms.
>>GNU C has »endian.h«, some systems have »sys/param.h«.
>
> The following code might not always yield the intended
> outcome as others have pointed out that some parts
> are not portable or well-defined, but it /is/ compiled
> with »constexpr«.
>
>#include <iostream>
>#include <ostream>
>
>constexpr bool endian()
>{ using bytes = struct { char a; };
> using overlay = union { int i; bytes b; };
> return overlay{ 1 }.b.a; }
>
>int main()
>{ ::std::cout << "endian()" << " = " << endian() << '\n'; }
>
> One could add security / sanity checks, such as statically
> asserting that sizeof( char)< sizeof( int ) or that one of
> the bytes is one and all preceding bytes are zero.
Does the rule that a constexpr cannot have "An lvalue-to-rvalue
implicit conversion applied to a non-active member of a union or its
subobject" apply here?
Öö Tiib
May 16, 2015, 5:38:35 AM5/16/15
to
specific headers and macros (or boost that uses all known such) then I
don't know a way to static_assert.
For avoiding total silence run-time you can make a startup test (static
storage object with runtime check in constructor).
woodb...@gmail.com
May 17, 2015, 12:47:39 PM5/17/15
to
On Friday, May 15, 2015 at 10:42:33 AM UTC-5, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> > Answer depends on if your question is of academical or of practical nature.
>
> I am making a library that handles binary data on a rather low level,
> and would require different code depending on endianness. However,
I have similar situation working with binary data in library code.
> Öö Tiib <oot...@hot.ee> wrote:
> > Answer depends on if your question is of academical or of practical nature.
>
> I am making a library that handles binary data on a rather low level,
> and would require different code depending on endianness. However,
I didn't find an approach I liked so I rely on users to read
the documentation and set -DCMW_BIG_ENDIAN if necessary. From
what I can tell, big-endian systems are fading from the landscape.
Brian
Ebenezer Enterprises
http://webEbenezer.net
Juha Nieminen
May 18, 2015, 5:39:24 AM5/18/15
to
Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> #include <iostream>
> #include <ostream>
>
> constexpr bool endian()
> { using bytes = struct { char a; };
> using overlay = union { int i; bytes b; };
> return overlay{ 1 }.b.a; }
>
> int main()
> { ::std::cout << "endian()" << " = " << endian() << '\n'; }
test.cc:2:16: error: constexpr function never produces a constant expression
> #include <iostream>
> #include <ostream>
>
> constexpr bool endian()
> { using bytes = struct { char a; };
> using overlay = union { int i; bytes b; };
> return overlay{ 1 }.b.a; }
>
> int main()
> { ::std::cout << "endian()" << " = " << endian() << '\n'; }
[-Winvalid-constexpr]
constexpr bool endian()
^
test.cc:5:23: note: read of member 'b' of union with active member 'i' is not
allowed in a constant expression
return overlay{ 1 }.b.a; }
Scott Lurndal
May 18, 2015, 9:45:56 AM5/18/15
to
>> =D6=F6 Tiib <oot...@hot.ee> wrote:
>> > Answer depends on if your question is of academical or of practical nat=
>ure.
>>=20
and you'll see why big-endian is still quite popular in networking
applications (routers, switches, security appliances, etc). Note
that the new ARM64 processor is capable of operating in either
(or both) endiannesses.
>> > Answer depends on if your question is of academical or of practical nat=
>ure.
>>=20
>> I am making a library that handles binary data on a rather low level,
>> and would require different code depending on endianness. However,
>
>I have similar situation working with binary data in library code.
>I didn't find an approach I liked so I rely on users to read=20
>> and would require different code depending on endianness. However,
>
>I have similar situation working with binary data in library code.
>the documentation and set -DCMW_BIG_ENDIAN if necessary. From
>what I can tell, big-endian systems are fading from the landscape.
Not true at all. Consider that network byte-order is big-endian,
>what I can tell, big-endian systems are fading from the landscape.
and you'll see why big-endian is still quite popular in networking
applications (routers, switches, security appliances, etc). Note
that the new ARM64 processor is capable of operating in either
(or both) endiannesses.
woodb...@gmail.com
May 18, 2015, 3:15:40 PM5/18/15
to
On Monday, May 18, 2015 at 8:45:56 AM UTC-5, Scott Lurndal wrote:
>
> Not true at all. Consider that network byte-order is big-endian,
> and you'll see why big-endian is still quite popular in networking
> applications (routers, switches, security appliances, etc). Note
> that the new ARM64 processor is capable of operating in either
> (or both) endiannesses.
That might be interesting if it were a big-endian only device.
>
> Not true at all. Consider that network byte-order is big-endian,
> and you'll see why big-endian is still quite popular in networking
> applications (routers, switches, security appliances, etc). Note
> that the new ARM64 processor is capable of operating in either
> (or both) endiannesses.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
blackball
May 19, 2015, 6:15:54 AM5/19/15
to
#define IS_BIG_ENDIAN (*((uint16_t *)"\0\xff") < 0x100)
Ben Bacarisse
May 19, 2015, 7:28:54 AM5/19/15
to
blackball <bug...@gmail.com> writes:
> On Friday, May 15, 2015 at 8:44:29 AM UTC+2, Juha Nieminen wrote:
>> Is it possible to determine endianess at compile time (in C++14)?
>>
>> At runtime it can be determined, for example, like this:
>>
>> bool isLittleEndianSystem()
>> {
>> unsigned value = 1;
>> unsigned char* ptr = (unsigned char*)&value;
>> return *ptr == 1;
>> }
<snip>
> On Friday, May 15, 2015 at 8:44:29 AM UTC+2, Juha Nieminen wrote:
>> Is it possible to determine endianess at compile time (in C++14)?
>>
>> At runtime it can be determined, for example, like this:
>>
>> bool isLittleEndianSystem()
>> {
>> unsigned value = 1;
>> unsigned char* ptr = (unsigned char*)&value;
>> return *ptr == 1;
>> }
> Using the C way:
>
> #define IS_BIG_ENDIAN (*((uint16_t *)"\0\xff") < 0x100)
uint16_t might not exist and the string need not be property aligned for
the pointer conversion) but, perhaps more to the point, it's not
guaranteed to be evaluated at compile time. (If I were replying to the
run-time example, I'd go with a compound literal union.)
The best was to make a test a compile-time test is to use what C calls
an integer constant expression, but I can't think of a way to write one
that expresses the endianality of the environment.
--
Ben.
Scott Lurndal
May 19, 2015, 9:21:38 AM5/19/15
to
woodb...@gmail.com writes:
>On Monday, May 18, 2015 at 8:45:56 AM UTC-5, Scott Lurndal wrote:
>>
>> Not true at all. Consider that network byte-order is big-endian,
>> and you'll see why big-endian is still quite popular in networking
>> applications (routers, switches, security appliances, etc). Note
>> that the new ARM64 processor is capable of operating in either
>> (or both) endiannesses.
>
>That might be interesting if it were a big-endian only device.
>
It can be big-endian, little-endian, or both. The point is that
>On Monday, May 18, 2015 at 8:45:56 AM UTC-5, Scott Lurndal wrote:
>>
>> Not true at all. Consider that network byte-order is big-endian,
>> and you'll see why big-endian is still quite popular in networking
>> applications (routers, switches, security appliances, etc). Note
>> that the new ARM64 processor is capable of operating in either
>> (or both) endiannesses.
>
>That might be interesting if it were a big-endian only device.
>
there is sufficient demand for new big-endian systems that a brand-spanking-new
architecture (AArch64) chose to include biendianness in the
architecture. if you think that choice was made arbitrarily, or
that that choice had no impact on the development of the
architecture or the implementations, then you have no idea
of what it takes to build a processor.
Richard
May 19, 2015, 11:46:04 AM5/19/15
to
[Please do not mail me a copy of your followup]
Ben Bacarisse <ben.u...@bsb.me.uk> spake the secret code
<87k2w4k...@bsb.me.uk> thusly:
>The best was to make a test a compile-time test is to use what C calls
>an integer constant expression, but I can't think of a way to write one
>that expresses the endianality of the environment.
that gives you the answer and use this to generate a header with the
necessary symbol defined.
Scott Lurndal
May 19, 2015, 12:47:47 PM5/19/15
to
legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>Ben Bacarisse <ben.u...@bsb.me.uk> spake the secret code
><87k2w4k...@bsb.me.uk> thusly:
>
>>The best was to make a test a compile-time test is to use what C calls
>>an integer constant expression, but I can't think of a way to write one
>>that expresses the endianality of the environment.
>
>I think I prefer the CMake way: simply execute a program at build time
>that gives you the answer and use this to generate a header with the
>necessary symbol defined.
Does that work when you're cross compiling for a different architecture
>[Please do not mail me a copy of your followup]
>
>Ben Bacarisse <ben.u...@bsb.me.uk> spake the secret code
><87k2w4k...@bsb.me.uk> thusly:
>
>>The best was to make a test a compile-time test is to use what C calls
>>an integer constant expression, but I can't think of a way to write one
>>that expresses the endianality of the environment.
>
>I think I prefer the CMake way: simply execute a program at build time
>that gives you the answer and use this to generate a header with the
>necessary symbol defined.
than that of the host?
Richard
May 19, 2015, 1:36:27 PM5/19/15
to
[Please do not mail me a copy of your followup]
sl...@pacbell.net spake the secret code
<JOJ6x.6331$Vk6....@fx22.iad> thusly:
>legaliz...@mail.xmission.com (Richard) writes:
>>I think I prefer the CMake way: simply execute a program at build time
>>that gives you the answer and use this to generate a header with the
>>necessary symbol defined.
>
>Does that work when you're cross compiling for a different architecture
>than that of the host?
file and the methods described on the wiki.
<http://www.vtk.org/Wiki/CMake_Cross_Compiling>
For endian-ness, this is probably more trouble than it is worth if you
need to support cross compiling. But system introspection is often
much more than a single boolean that is easily answered from the
command-line when you initiate a build of the code.
Juha Nieminen
May 20, 2015, 3:22:25 AM5/20/15
to
Richard <legaliz...@mail.xmission.com> wrote:
> I think I prefer the CMake way: simply execute a program at build time
> that gives you the answer and use this to generate a header with the
> necessary symbol defined.
I think a well-designed library ought to avoid requiring external
> I think I prefer the CMake way: simply execute a program at build time
> that gives you the answer and use this to generate a header with the
> necessary symbol defined.
compiling tools if possible. If I can make a library as "plug&play"
as possible, I very much prefer that.
Scott Lurndal
May 20, 2015, 10:09:37 AM5/20/15
to
legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><JOJ6x.6331$Vk6....@fx22.iad> thusly:
>
>>legaliz...@mail.xmission.com (Richard) writes:
>>>I think I prefer the CMake way: simply execute a program at build time
>>>that gives you the answer and use this to generate a header with the
>>>necessary symbol defined.
>>
>>Does that work when you're cross compiling for a different architecture
>>than that of the host?
>
>When cross compiling you describe the target system with a toolchain
>file and the methods described on the wiki.
><http://www.vtk.org/Wiki/CMake_Cross_Compiling>
In other words, no, that won't work when cross compliing for
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><JOJ6x.6331$Vk6....@fx22.iad> thusly:
>
>>legaliz...@mail.xmission.com (Richard) writes:
>>>I think I prefer the CMake way: simply execute a program at build time
>>>that gives you the answer and use this to generate a header with the
>>>necessary symbol defined.
>>
>>Does that work when you're cross compiling for a different architecture
>>than that of the host?
>
>When cross compiling you describe the target system with a toolchain
>file and the methods described on the wiki.
><http://www.vtk.org/Wiki/CMake_Cross_Compiling>
different architectures.
As someone who has been developing operating systems[*] on big, little
and bi-endian systems since 1979, I'm quite comfortable with using
the implementation header files (included as part of the tool chain)
to determine the endianness on unix, unix-like and linux systems.
That's why I'm also comfortable using dual leading underscores for
defines, because when I do, it _is_ part of the implementation. Granted,
I should have edited the example I posted earlier to avoid encouraging
misuse by readers writing application level code.
[*] including the compilation tools (e.g. pcc), associated header files
standard libraries etc.
Richard
May 21, 2015, 3:40:17 PM5/21/15
to
<rA07x.22827$WG1....@fx04.iad> thusly:
>That's why I'm also comfortable using dual leading underscores for
>defines, because when I do, it _is_ part of the implementation.
If you're implementing the standard library, then double underscore
identifiers are reserved for you.
If you're not implementing the standard library, then you shouldn't
have any identifiers containing double underscores.
It's really that simple, but so many people (including tool vendors
happily generating code from templates that creates application code
using reserved identifiers) do not know this or understand it.
>That's why I'm also comfortable using dual leading underscores for
>defines, because when I do, it _is_ part of the implementation.
identifiers are reserved for you.
If you're not implementing the standard library, then you shouldn't
have any identifiers containing double underscores.
It's really that simple, but so many people (including tool vendors
happily generating code from templates that creates application code
using reserved identifiers) do not know this or understand it.
Öö Tiib
May 22, 2015, 2:20:13 AM5/22/15
to
On Thursday, 21 May 2015 22:40:17 UTC+3, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> sl...@pacbell.net spake the secret code
> <rA07x.22827$WG1....@fx04.iad> thusly:
>
> >That's why I'm also comfortable using dual leading underscores for
> >defines, because when I do, it _is_ part of the implementation.
>
> If you're implementing the standard library, then double underscore
> identifiers are reserved for you.
You should also use those underscores when you are implementing
> [Please do not mail me a copy of your followup]
>
> sl...@pacbell.net spake the secret code
> <rA07x.22827$WG1....@fx04.iad> thusly:
>
> >That's why I'm also comfortable using dual leading underscores for
> >defines, because when I do, it _is_ part of the implementation.
>
> If you're implementing the standard library, then double underscore
> identifiers are reserved for you.
something that standard libraries will be built upon (IOW platform).
It is so because implementation should not expose ordinary names
(that do not contain these underscores) that may conflict with
program code. Being mostly templates and header-only it is difficult to
not expose names of dependencies.
> If you're not implementing the standard library, then you shouldn't
> have any identifiers containing double underscores.
>
> It's really that simple, but so many people (including tool vendors
> happily generating code from templates that creates application code
> using reserved identifiers) do not know this or understand it.
people read source codes of standard library or platform and mimic
the idioms in their application code.
Juha Nieminen
May 22, 2015, 5:48:53 AM5/22/15
to
Öö Tiib <oot...@hot.ee> wrote:
> You should also use those underscores when you are implementing
> something that standard libraries will be built upon (IOW platform).
> It is so because implementation should not expose ordinary names
> (that do not contain these underscores) that may conflict with
> program code. Being mostly templates and header-only it is difficult to
> not expose names of dependencies.
If you use underscores in your own code, you run the risk of your
> You should also use those underscores when you are implementing
> something that standard libraries will be built upon (IOW platform).
> It is so because implementation should not expose ordinary names
> (that do not contain these underscores) that may conflict with
> program code. Being mostly templates and header-only it is difficult to
> not expose names of dependencies.
library not working with another compiler or with a newer version
of the same compiler.
Scott Lurndal
May 22, 2015, 9:56:38 AM5/22/15
to
legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><rA07x.22827$WG1....@fx04.iad> thusly:
>
>>That's why I'm also comfortable using dual leading underscores for
>>defines, because when I do, it _is_ part of the implementation.
>
>If you're implementing the standard library, then double underscore
>identifiers are reserved for you.
As I said, I was implementing a standard library (libc, as a matter
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><rA07x.22827$WG1....@fx04.iad> thusly:
>
>>That's why I'm also comfortable using dual leading underscores for
>>defines, because when I do, it _is_ part of the implementation.
>
>If you're implementing the standard library, then double underscore
>identifiers are reserved for you.
of fact).
The entire implementation is allowed to use __, not just C++
header files.
Richard
May 22, 2015, 11:12:01 AM5/22/15
to
<fAG7x.8001$Wq5....@fx16.iad> thusly:
I thought I was being explicit enough, but apparently not, so I'll say
it again:
I agree with you.
When you are implementing the standard library you can use identifiers
with __.
it again:
I agree with you.
When you are implementing the standard library you can use identifiers
with __.
woodb...@gmail.com
May 24, 2015, 3:16:01 PM5/24/15
to
On Tuesday, May 19, 2015 at 8:21:38 AM UTC-5, Scott Lurndal wrote:
As far as I can tell using big-endian for network order was
an arbitrary choice.
> woodb...@gmail.com writes:
> >
> >That might be interesting if it were a big-endian only device.
> >
>
> It can be big-endian, little-endian, or both. The point is that
> there is sufficient demand for new big-endian systems that a brand-spanking-new
> architecture (AArch64) chose to include biendianness in the
> architecture. if you think that choice was made arbitrarily, or
> that that choice had no impact on the development of the
> architecture or the implementations, then you have no idea
> of what it takes to build a processor.
https://fgiesen.wordpress.com/2014/10/25/little-endian-vs-big-endian/
> >
> >That might be interesting if it were a big-endian only device.
> >
>
> It can be big-endian, little-endian, or both. The point is that
> there is sufficient demand for new big-endian systems that a brand-spanking-new
> architecture (AArch64) chose to include biendianness in the
> architecture. if you think that choice was made arbitrarily, or
> that that choice had no impact on the development of the
> architecture or the implementations, then you have no idea
> of what it takes to build a processor.
As far as I can tell using big-endian for network order was
an arbitrary choice.
Öö Tiib
May 25, 2015, 9:36:49 AM5/25/15
to
but that does not mean that usage of big-endian in architectures of
some systems is arbitrary decision. Besides ... you can get ten
different answers to any question from random blogs in internet.
David Brown
May 25, 2015, 10:30:37 AM5/25/15
to
the other in architecture design. Big-endian is apparently easier to
implement efficiently in hardware, especially for wider paths - hence
its popularity in many RISC designs. Little-endian is convenient for
arithmetic with multi-byte values, hence its popularity with 8-bit
designs or those that can trace their ancestry back to 8-bit designs.
The most common reason for choosing one format over the other is, of
course, consistency with some particular previous system.
Ben Bacarisse
May 25, 2015, 12:23:22 PM5/25/15
to
<snip>
that I've been around long enough to confirm that the idea is an old
one), it was said that you could route packets faster if the high-order
bits of address came down the line first, since that's often the only
part you need to determine the route.
--
Ben.
>> As far as I can tell using big-endian for network order was
>> an arbitrary choice.
>
> Picking big-endian for network order was possibly arbitrary decision
> but that does not mean that usage of big-endian in architectures of
> some systems is arbitrary decision. Besides ... you can get ten
> different answers to any question from random blogs in internet.
To give one just one (with no more authoritative backing than the fact
>> an arbitrary choice.
>
> Picking big-endian for network order was possibly arbitrary decision
> but that does not mean that usage of big-endian in architectures of
> some systems is arbitrary decision. Besides ... you can get ten
> different answers to any question from random blogs in internet.
that I've been around long enough to confirm that the idea is an old
one), it was said that you could route packets faster if the high-order
bits of address came down the line first, since that's often the only
part you need to determine the route.
--
Ben.
Juha Nieminen
May 25, 2015, 12:30:22 PM5/25/15
to
David Brown <david...@hesbynett.no> wrote:
> There are a few good technical reasons for preferring one format over
> the other in architecture design. Big-endian is apparently easier to
> implement efficiently in hardware, especially for wider paths - hence
> its popularity in many RISC designs.
In a big-endian system string comparisons can be made more efficient
> There are a few good technical reasons for preferring one format over
> the other in architecture design. Big-endian is apparently easier to
> implement efficiently in hardware, especially for wider paths - hence
> its popularity in many RISC designs.
because you can directly compare strings as if they were unsigned long
arrays (assuming enough padding at the end of the string).
0 new messages