*(I guess this question could apply to many typed languages, but I chose to use C++ as an example.)*

Why is there no way to just write:

    struct foo {
        little int x;   // little-endian
        big long int y; // big-endian
        short z;        // native endianness
    };

to specify the endianness for specific members, variables and parameters?

## Comparison to signedness

I understand that the type of a variable not only determines how many bytes are used to store a value but also how those bytes are interpreted when performing computations.

For example, these two declarations each allocate one byte, and for both bytes, every possible 8-bit sequence is a valid value:

    signed char s;
    unsigned char u;

but the same binary sequence might be interpreted differently, e.g. `11111111` would mean -1 when assigned to `s` but 255 when assigned to `u`. When signed and unsigned variables are involved in the same computation, the compiler (mostly) takes care of proper conversions.

In my understanding, endianness is just a variation of the same principle: a different interpretation of a binary pattern based on compile-time information about the memory in which it will be stored.

It seems obvious to have that feature in a typed language that allows low-level programming. However, this is not a part of C, C++ or any other language I know, and I did not find any discussion about this online.

# Update

I&#39;ll try to summarize some takeaways from the many comments that I got in the first hour after asking:

 

 1. signedness is strictly binary (either signed or unsigned) and will always be, in contrast to endianness, which also has two well-known variants (big and little), but also lesser-known variants such as mixed/middle endian. New variants might be invented in the future.
 2. endianness matters when accessing multiple-byte values byte-wise. There are many aspects beyond just endianness that affect the memory layout of multi-byte structures, so this kind of access is mostly discouraged.
 3. C++ aims to target an [abstract machine][1] and minimize the number of assumptions about the implementation. This abstract machine does not have _any_ endianness.

Also, now I realize that signedness and endianness are not a perfect analogy, because:

 * endianness only defines _how_ something is represented as a binary sequence, but now _what can be_ represented. Both `big int` and `little int` would have the exact same value range.
 * signedness defines _how_ bits and actual values map to each other, but also affects _what can be_ represented, e.g. -3 can&#39;t be represented by an `unsigned char` and (assuming that `char` has 8 bits) 130 can&#39;t be represented by a `signed char`.

So that changing the endianness of some variables would never change the behavior of the program (except for byte-wise access), whereas a change of signedness usually would.

  [1]: http://eel.is/c++draft/intro.abstract#1 

Why isn&#39;t there an endianness modifier in C++ like there is for signedness?

I have an array of Floats that need to be converted to a byte array and back to a float[]... can anyone help me do this correctly?  

I&#39;m working with the bitConverter class and found myself stuck trying to append the results.

The reason I&#39;m doing this is so I can save runtime values into a IO Stream.  The target storage is Azure Page blobs in case that matters.  I don&#39;t care about what endian this is stored in, as long as it input matches the output.

   

    static  byte[] ConvertFloatToByteArray(float[] floats)
            {
                byte[] ret = new byte[floats.Length * 4];// a single float is 4 bytes/32 bits
    
                for (int i = 0; i &lt; floats.Length; i++)
                {
                   // todo: stuck...I need to append the results to an offset of ret
                    ret = BitConverter.GetBytes(floats[i]);
    
                }
                return ret;
            }


     static  float[] ConvertByteArrayToFloat(byte[] bytes)
    { //to do }



How do I convert an array of floats to a byte[] and back?

Why are both little- and big-endian still in use __today__, after ~40 years of binary computer-science? Are there algorithms or storage formats that work better with one and much worse with the other? Wouldn&#39;t it be better if we all switched to one and stick with it?

Why are both little- and big-endian in use?

How do I convert between big-endian and little-endian values in C++?

For clarity, I have to translate binary data (double-precision floating point values and 32-bit and 64-bit integers) from one CPU architecture to another.  This doesn&#39;t involve networking, so ntoh() and similar functions won&#39;t work here.

---

Note: The answer I accepted applies directly to compilers I&#39;m targeting (which is why I chose it).  However, there are other very good, more portable answers here.

How do I convert between big-endian and little-endian values in C++?

Is there a programmatic way to detect whether or not you are on a big-endian or little-endian architecture?  I need to be able to write code that will execute on an Intel or PPC system and use exactly the same code (i.e. no conditional compilation).

Detecting endianness programmatically in a C++ program

Suppose I have the number `&#39;numb&#39;=1025 [00000000 00000000 00000100 00000001]` represented:

On Little-Endian Machine:

    00000001 00000100 00000000 00000000

On Big-Endian Machine:

    00000000 00000000 00000100 00000001

Now, if I apply Left Shift on 10 bits (i.e.: numb &lt;&lt;= 10), I should have:

[A] On Little-Endian Machine:

As I noticed in GDB, Little Endian does the Left Shift in 3 steps: [I have shown &#39;3&#39; Steps to better understand the processing only]

1. Treat the no. in Big-Endian Convention:

        00000000        00000000        00000100	00000001

2. Apply Left-Shift:

        00000000        00010000        00000100        00000000

3. Represent the Result again in Little-Endian:

        00000000        00000100        00010000        00000000 

[B]. On Big-Endian Machine:

    00000000        00010000        00000100        00000000


----------


My Question is:

If I directly apply a Left Shift on the Little Endian 
Convention, it should give:

`numb`:

    00000001 00000100 00000000 00000000

`numb &lt;&lt; 10`:

    00010000 00000000 00000000 00000000

But actually, it gives:

    00000000        00000100        00010000        00000000 

To achieve the second result only, I have shown three hypothetical steps above.

Please explain me why the above two results are different: The actual outcome of `numb &lt;&lt; 10` is different than the expected outcome.

Does bit-shift depend on endianness?

I want to store some data into byte arrays in Java. Basically just numbers which can take up to 2 Bytes per number.

I&#39;d like to know how I can convert an integer into a 2 byte long byte array and vice versa. I found a lot of solutions googling but most of them don&#39;t explain what happens in the code. There&#39;s a lot of shifting stuff I don&#39;t really understand so I would appreciate a basic explanation.

Convert a byte array to integer in Java and vice versa

Is there a one line macro definition to determine the endianness of the machine? I am using the following code but converting it to macro would be too long:

    unsigned char test_endian( void )
    {
        int test_var = 1;
        unsigned char *test_endian = (unsigned char*)&amp;test_var;
    
        return (test_endian[0] == 0);
    }


Macro definition to determine big endian or little endian machine?

I need to write a function to convert big endian to little endian in C. I can not use any library function.


convert big endian to little endian in C [without using provided func]

I ask because I am sending a byte stream from a C process to Java. On the C side the 32 bit integer has the LSB is the first byte and MSB is the 4th byte.

So my question is: On the Java side when we read the byte as it was sent from the C process, what is [endian][1] on the Java side?

A follow-up question: If the endian on the Java side is not the same as the one sent, how can I convert between them?


  [1]: https://en.wikipedia.org/wiki/Endianness

Does Java read integers in little endian or big endian?

As written in the heading, my question is, why does **TCP/IP** use big endian encoding when transmitting data and not the alternative little-endian scheme?

Why is network-byte-order defined to be big-endian?

I read that the order of bit fields within a struct is platform specific.  What about if I use different compiler-specific packing options, will this guarantee data is stored in the proper order as they are written?  For example:

    struct Message
    {
      unsigned int version : 3;
      unsigned int type : 1;
      unsigned int id : 5;
      unsigned int data : 6;
    } __attribute__ ((__packed__));

On an Intel processor with the GCC compiler, the fields were laid out in memory as they are shown. `Message.version` was the first 3 bits in the buffer, and `Message.type` followed. If I find equivalent struct packing options for various compilers, will this be cross-platform?

C/C++: Force Bit Field Order and Alignment

How to check whether a system is big endian or little endian?

    #include &lt;stdio.h&gt;
    
    int main() {
        float a = 1234.5f;
        printf(&quot;%d\n&quot;, a);
        return 0;
    }

It displays a `0`!! How is that possible? What is the reasoning?


----------
I have deliberately put a `%d` in the `printf` statement to study the behaviour of `printf`.

How does this program work?

Does [endianness][1] matter at all with the bitwise operations? Either [logical][2] or shifting? 

I&#39;m working on homework with regard to bitwise operators, and I can not make heads or tails on it, and I think I&#39;m getting quite hung up on the endianess. That is, I&#39;m using a little endian machine (like most are), but does this need to be considered or is it a wasted fact? 

In case it matters, I&#39;m using C.

  [1]: http://en.wikipedia.org/wiki/Endianness
  [2]: https://stackoverflow.com/questions/1036141/bitwise-not-operator-in-c-with-regards-to-little-endian-and-big-endian


Bitwise operators and &quot;endianness&quot;

&gt; **Possible Duplicate:**  
&gt; [C Macro definition to determine big endian or little endian machine?](https://stackoverflow.com/questions/2100331/c-macro-definition-to-determine-big-endian-or-little-endian-machine)  

&lt;!-- End of automatically inserted text --&gt;

    int main()
    {
      int x = 1;
    
      char *y = (char*)&amp;x;
    
      printf(&quot;%c\n&quot;,*y+48);
    }


If it&#39;s little endian it will print 1.  If it&#39;s big endian it will print 0.  Is that correct?  Or will setting a char* to int x always point to the least significant bit, regardless of endianness?

C program to check little vs. big endian

I&#39;m working on an implementation of the memcache protocol which, at some points, uses 64 bits integer values. These values must be stored in &quot;network byte order&quot;.

I wish there was some `uint64_t htonll(uint64_t value)` function to do the change, but unfortunately, if it exist, I couldn&#39;t find it.

So I have 1 or 2 questions:

 * Is there any **portable** (Windows, Linux, AIX) standard function to do this ?
 * If there is no such function, how would you implement it ?

I have in mind a basic implementation but I don&#39;t know how to check the endianness at compile-time to make the code portable. So your help is more than welcome here ;)

Thank you.

&lt;hr/&gt;

Here is the final solution I wrote, thanks to Brian&#39;s solution.

	uint64_t htonll(uint64_t value)
	{
		// The answer is 42
		static const int num = 42;

		// Check the endianness
		if (*reinterpret_cast&lt;const char*&gt;(&amp;num) == num)
		{
			const uint32_t high_part = htonl(static_cast&lt;uint32_t&gt;(value &gt;&gt; 32));
			const uint32_t low_part = htonl(static_cast&lt;uint32_t&gt;(value &amp; 0xFFFFFFFFLL));

			return (static_cast&lt;uint64_t&gt;(low_part) &lt;&lt; 32) | high_part;
		} else
		{
			return value;
		}
	}

Is there any &quot;standard&quot; htonl-like function for 64 bits integers in C++?

What is the difference between Big Endian and Little Endian Byte order ?

Both of these seem to be related to Unicode and UTF16. Where exactly do we use this?


Difference between Big Endian and little Endian Byte order

Endianness from what I understand, is when the bytes that compose a multibyte word differ in their order, at least in the most typical case.  So that an 16-bit integer may be stored as either `0xHHLL` or `0xLLHH`.  

Assuming I don&#39;t have that wrong, what I would like to know is when does Endianness become a major factor when sending information between two computers where the Endian may or may not be different.

 * If I transmit a short integer of 1, in the form of a char array and with no correction, is it received and interpretted as 256?

 * If I decompose and recompose the short integer using the following code, will endianness no longer be a factor?


        // Sender:
        for(n=0, n &lt; sizeof(uint16)*8; ++n) {
            stl_bitset[n] = (value &gt;&gt; n) &amp; 1;
        };

        // Receiver:
        for(n=0, n &lt; sizeof(uint16)*8; ++n) {
            value |= uint16(stl_bitset[n] &amp; 1) &lt;&lt; n;
        };
 *  Is there a standard way of compensating for endianness?

Thanks in advance!

When does Endianness become a factor?

I&#39;m using WebGL to render a binary encoded mesh file. The binary file is written out in big-endian format (I can verify this by opening the file in a hex editor, or viewing the network traffic using fiddler). When I try to read the binary response using a Float32Array or Int32Array, the binary is interpreted as little-endian and my values are wrong:

    // Interpret first 32bits in buffer as an int
    var wrongValue = new Int32Array(binaryArrayBuffer)[0];

I can&#39;t find any references to the default endianness of typed arrays in &lt;http://www.khronos.org/registry/typedarray/specs/latest/&gt; so I&#39;m wondering what&#39;s the deal? Should I assume that all binary data should be little-endian when reading using typed arrays?

To get around the problem I can use a DataView object (discussed in the previous link) and call:

    // Interpret first 32bits in buffer as an int
    var correctValue = new DataView(binaryArrayBuffer).getInt32(0);

The DataView functions such as &quot;getInt32&quot; read big-endian values by default.

(Note: I&#39;ve tested using Google Chrome 15 and Firefox 8 and they both behave the same way)

Javascript Typed Arrays and Endianness

Is there a safe, portable way to determine (during compile time) the endianness of the platform that my program is being compiled on? I&#39;m writing in C.

[EDIT]
Thanks for the answers, I decided to stick with the runtime solution!

Determining endianness at compile time

In the documentation of hardware that allows us to control it via UDP/IP,
I found the following fragment:

&gt; In this communication protocol, DWORD is a 4 bytes data, WORD is a 2 bytes data,
&gt; BYTE is a single byte data. The storage format is little endian, namely 4 bytes (32bits) data is stored as: d7-d0, d15-d8, d23-d16, d31-d24; double bytes (16bits) data is stored as: d7-d0 , d15-d8.

I am wondering how this translates to C#?
Do I have to convert stuff before sending it over?
For example, if I want to send over a 32 bit integer, or a 4 character string?





C# little endian or big endian?

The man pages for `htonl()` seem to suggest that you can only use it for up to 32 bit values. (In reality, `ntohl()` is defined for unsigned long, which on my platform is 32 bits. I suppose if the unsigned long were 8 bytes, it would work for 64 bit ints).

My problem is that I need to convert 64 bit integers (in my case, this is an unsigned long long) from big endian to little endian. Right now, I need to do that specific conversion. But it would be even nicer if the function (like `ntohl()`) would NOT convert my 64 bit value if the target platform WAS big endian. (I&#39;d rather avoid adding my own preprocessor magic to do this).

What can I use? I would like something that is standard if it exists, but I am open to implementation suggestions. I have seen this type of conversion done in the past using unions. I suppose I could have a union with an unsigned long long and a char[8]. Then swap the bytes around accordingly. (Obviously would break on platforms that were big endian).

64 bit ntohl() in C++?

A real question that I&#39;ve been asking myself lately is what design choices brought about x86 being a little endian architecture instead of a big endian architecture?

All Endianness Solutions on Gang of Coders

Total of 24 Endianness Solutions

Why isn't there an endianness modifier in C++ like there is for signedness?