#How to check which endian is CPU using?

1 messages · Page 1 of 1 (latest)

chilly stream
#

I have this code:

big_endian_warn :: proc() {
    endianCheck: struct #raw_union {
        u64: u64,
        u8:  u8,
    }
    endianCheck.u8 = 1
    if endianCheck.u64 != u64(endianCheck.u8) {
        fmt.println("WARNING: Your CPU is Big-Endian, test results will be different!")
    }
}

Is this correct?
And is there a more succinct way?

median tendon
#

I think you can use the built in constant ODIN_ENDIAN

chilly stream
#

When is ODIN_ENDIAN "Unknown"?

burnt shadow
#

Pretty much every platform nowadays will be little endian any way.

chilly stream
#

Tnx!
I still need to warn the user.

#

Not a fan of the fact that anything over the net needs to be big endian tho :/

burnt shadow
#

It doesn't need to be.

#

Where the heck do you get that idea from?

#

Many of the base protocols are big endian, but that doesn't mean you have to write any of your protocols using big endian.

#

Like TCP is big endian, but your protocol based on top of it doesn't need to be.

chilly stream
#

if you are in charge of both ends, it does not matter.
But when communicating with unknown machine, it is assumed the data is BE

burnt shadow
#

Says who?!

#

Odin also has endian specific types too, by the way.

#

Specifically for this reason.

chilly stream
#

"network order" is defined as BE... Sadly

burnt shadow
#

...

#

Is this your own protocol that you are making on top of TCP or UDP?

chilly stream
#

I am not making my own, if I were, I would define it to be LE

burnt shadow
#

Ah.

#

Then can you not use the *be types?

chilly stream
#

yeah

#

But I am just lamenting the fact that BE is a thing :D

#

It is humans that should use LE when representing numbers :D

burnt shadow
#

Actually the opposite. 8 thousand 3 hundred and twelve 8312 is in big-endian.

#

Little endian is what a lot of platforms use nowadays because it is easier to do conversions between different sized integers.

chilly stream
burnt shadow
#

It is humans that should use LE when representing numbers 😄

#

You said the opposite 😛

chilly stream
#

I said "should", not "are"

burnt shadow
#

Ah.

#

Sorry I misread.

chilly stream
#

happends to the best of us

naive wraith
# chilly stream "network order" is defined as BE... Sadly

It's worth pointing out that, as a general statement, "network order is BE", is just a convention.
There is nothing at all that inherently enforces that.
One can send LE data over the network just fine; the actual network only cares that you gave it bytes.

#

Or wait - actually, "network order is BE" doesn't really make sense on its own, because of that last statement: the actual network only cares you gave it bytes.

#

Bytes don't have an endianness.

chilly stream
naive wraith
#

Like - it makes sense if you say that "I have to send a 4 byte integer over the network; I'm going to always convert those to BE so that both sides can understand it regardless of their native endianness."
But it doesn't make sense to say that the network requires it you to do that.

#

i.e: You could choose to always convert to LE instead, and you'd be just as fine, so long as both sides know that.

chilly stream
#

Indeed

#

😄

naive wraith
#

🤣

#

👍

chilly stream
#

As I already went trough with bill, yep

#

I have not checked, but I would bet that most libraries for "pumping/sucking things over the wire" just flat out assume BE. That is the fact I am lamenting.

naive wraith
#

BE also makes it easier to read an integer, given the bytes in the received order, too. Which can help debugging or reverse engineering. But that applies to things like file formats too.

tardy ember
chilly stream
#

Tnx for the link!