little endian machines

Code:

---

#include <stdio.h>
 
int main()
{
        union s
      {
            int i;
            char ch[2];
      };
 
 
union s obj;
obj.i=255;
printf("%d %d %d\n",obj.i,obj.ch[0],obj.ch[1]);


}

---

o/p :

255 -1 0

But what i expected was 255 255 0
But How that -1 ?
Explain please ?

Thanks
yogeesh serlathan

forum4hackers.blogspot.com

You might want to specify ch as an array of unsigned char. char can be signed or unsigned, depending on the implementation.

My first post here so Hi everybody.

00000000 00000000 00000000 11111111 is binary of your 255, int is 32 bits long on gcc.
With little endian this data is stored in memory in reverse byte order so you have:
11111111 00000000 00000000 00000000
Binary representation of -1 is 1111 1111 when variable is signed. 1111 1110 is -2 and so on.
You can even access 2nd and 3rd element of this array:

Code:

---

union u {
        int iNum;
        char aChar[2];
    }uVar={.iNum=255};
    printf("%d, %d, %d %d %d\n", uVar.iNum, uVar.aChar[0], uVar.aChar[1], uVar.aChar[2], uVar.aChar[3]);

---

ps sorry for my poor english

Don't use unions like that. It'll usually work, but technically the C++ standard only permits reading the union element that was last written to. In other words, you can't write iNum and then read aChar, unless you're cool with implementation-specific behavior.


P.S. In C++, it's not <stdio.h> but <cstdio>. All the old headers from the C standard libary can be gotten at by dropping the ".h" and prepending a "c".

<assert.h> -> <cassert>
<stdlib.h> -> <cstdlib>
<stddef.h> -> <cstddef>

etc.

That also means that all the functions, types, etc. that used to be in the old headers are now in namespace std, so technically you should be writing std::printf() instead of just printf().

Quote:

---

Originally Posted by antred

That also means that all the functions, types, etc. that used to be in the old headers are now in namespace std, so technically you should be writing std::printf() instead of just printf().

---

Or... you know, just use std::cout.

Quote:

---

Originally Posted by antred

Don't use unions like that. It'll usually work, but technically the C++ standard only permits reading the union element that was last written to. In other words, you can't write iNum and then read aChar, unless you're cool with implementation-specific behavior.

---

Well, yeah - but it is also a moot point.

Every available approach for reinterpreting types (eg interpreting the memory representing an X as if it was a Y) yields some form of implementation defined or undefined behaviour.

Quote:

---

Originally Posted by grumpy

Every available approach for reinterpreting types (eg interpreting the memory representing an X as if it was a Y) yields some form of implementation defined or undefined behaviour.

---

Well, that's true I guess but then I don't see any need for that kind of stuff if all you want to do is endianness-related conversions. Oh and correct me if I'm wrong, but shouldn't the following be free of any "undefinedness"?

Code:

---

#include <iostream>

bool isLittleEndian()
{
    const unsigned char byteArray[ sizeof( unsigned short int ) ] = { 1 };
    const unsigned short int* const asUShort = reinterpret_cast < const unsigned short int* > ( byteArray );

    return *asUShort == static_cast < unsigned short int > ( byteArray[ 0 ] );
}

int main()
{
    if ( isLittleEndian() )
    {
        std::cout << "little-endian\n";
    }
    else
    {
        std::cout << "big-endian\n";
    }
}

---

I don't think there is anything implementation-specific in the memory representation of unsigned, built-in integral types, or is there?

P.S. Except of course sizeof( unsigned int ), etc. ...

Nope. The code exhibits undefined behaviour when dereferencing asUShort.

Quote:

---

Originally Posted by grumpy

Nope. The code exhibits undefined behaviour when dereferencing asUShort.

---

Seriously? Can you explain why (or point me to the relevant section in the C++ standard)?

Ah well, found it. It seems you're right.

Quote:

---

5.2.10 Reinterpret cast
3) The mapping performed by reinterpret_cast is implementation-defined. [Note: it might, or might
not, produce a representation different from the original value. ]

---

And no mention of any exceptions to this rule.

You could write the array to file and then read it into the other array :p

Okay okay, I'm just getting silly there.

Quote:

---

Originally Posted by antred

And no mention of any exceptions to this rule.

---

What you found about reinterpret_cast<> is only part of it.

The reinterpret_cast<> has implementation defined behaviour, as you have found.

Regardless of how the reinterpret_cast<> does any mapping, the dereferencing of asUShort (i.e. the "*asUShort") ALSO has undefined behaviour, since it treats memory containing a value of type X as if it was a value of type Y.

Quote:

---

has undefined behaviour

---

I'm not on a machine that has the standard available so I'm compelled (by curiosity) to ask: isn't that still implemented defined instead of undefined?

Soma

Type conversions between values (even pointer values) give implementation-defined results.

Dereferencing a pointer has undefined behaviour, if the pointer is of a different type from what is actually stored at that address.

Quote:

---

Type conversions between values (even pointer values) give implementation-defined results.

---

With the exception that normal pointers must "round trip" through `void *' of course.

Quote:

---

Dereferencing a pointer has undefined behaviour, if the pointer is of a different type from what is actually stored at that address.

---

Yes. I understood what you were saying. I wasn't arguing with you about it. I was hoping you could give the context from the standard for it.

I wasn't looking for a quote of anything. I was just looking for the context of that portion of the standard. I can look it up myself later.

Soma

As you say, round trips through a void pointer (for anything except a pointer to member) are a specific exception, identified in the standard. That still, however, doesn't allow you to dereference a pointer to char as if it was an int.

Unfortunately, your search will be more difficult than finding a clause that says this is undefined behaviour, because this is one of those things that the standard leaves undefined, by omission, so you won't find a specific clause saying it is undefined.

As per Section 1.3.12 "Undefined behavior" of ISO/IEC 14882 (aka the 1998 C++ standard)

Quote:

---

behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior.

---

I've added the bold for emphasis.

If you do a hunt through, you will find all sorts of things (such as the clauses that result in a round-trip through a void pointer being valid) about what is allowed. It is the omissions that are important (and I assume the omissions occurred because it would have been very difficult to comprehensively articulate all possible cases of undefined behaviour).

Incidentally, I can't claim credit (if credit it is) for this interpretation. Several mainstream compiler vendors, in reference to all C and C++ standard since 1989, have interpreted the standard that way. And I have yet to see anyone find a convincing interpretation of any clause in the standards that allows a rebuttal. Given that history, I might still be wrong in my interpretation, but I won't hold my breath in anticipation of being proven wrong.

The various methods of determining endianness at runtime may result in undefined or implementation-defined behavior, and yet these are the only methods available. The problem must be solved at any rate.