Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on What is CPU endianness?

Post

What is CPU endianness?

+10
−0

I was fooling around with the following C code on my trusty old x86 PC:

#include <stdint.h>
#include <stdio.h>

int main (void)
{
  uint32_t u32 = 0xAABBCCDD;
  uint8_t* ptr = (uint8_t*)&u32;
  for(size_t i=0; i<sizeof(uint32_t); i++)
  {
    printf("%.2X", ptr[i]);
  }
}

To my surprise, this prints DDCCBBAA with all bytes backwards. Someone told me this was because of "endianness" and that my x86 is "little endian". What is the meaning of this?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (7 comments)
General comments
C. K. Young‭ wrote almost 4 years ago · edited almost 4 years ago

The code snippet in the question violates the strict aliasing rule, and is undefined behaviour. :-( The safe C way to type-pun is to use a union. I'll post a suggested edit with this (feel free to reformat/edit to taste).

Lundin‭ wrote almost 4 years ago · edited almost 4 years ago

@Chris Jester-Young‭ No, that's wrong. There is a special rule allowing us to inspect any type in C by using a character type (uint8_t is always a character type if supported). C17 6.3.2.3/7. "When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object."

Lundin‭ wrote almost 4 years ago

@Chris Jester-Young‭ Furthermore, if you read the actual "strict aliasing rule", it has an explicit exception for lvalue access through a character type. C17 6.5/7: "An object shall have its stored value accessed only by an lvalue expression that has one of the following types: ... - a character type."

dmckee‭ wrote almost 4 years ago

Anyone one who regularly crosses the line between c and c++ should keep in mind that c++’s strict aliasing rule is stricter than c’s. Punning in-place is possible a couple of ways in c and essentially forbidden in c++. Drives me bats because the committee could have made an exception for POD types, but there you have it.

jrh‭ wrote almost 4 years ago · edited almost 4 years ago

@dmckee you can use attributes to make specific types exempt from strict aliasing, also note that MSVC has no strict aliasing. Lundin, would you add this attribute to your post behind a "not MSVC" guard? Or mention fno-strict-aliasing? I've found that very few people know about type punning and I've found some real messes over the years.

Skipping 1 deleted comment.

jrh‭ wrote almost 4 years ago

Ok, I'm not really 100% sure whether you avoided type punning UB, to be very pedantic about it uint8_t* is probably a char but might not be, you might not be completely off the hook in C either

Lundin‭ wrote almost 4 years ago

@jrh uint8_t will have to be a character type if supported, I've written answers explaining why on SO. But please don't derail comments further; this has nothing to do with endianess. If you have a question about strict aliasing, please ask a separate question.