"Big endian"
-
"Big endian"
What it suggests (
️DON'T read this):
"The big (most significant) byte is at the end"
What it actually means (explained to humans):
"The starting extreme of the number is the big (most significant byte) one"
Convention perpetrated by the utterly deranged
-
"Big endian"
️DON'T read this):
"The big (most significant) byte is at the end"
"The starting extreme of the number is the big (most significant byte) one"
Convention perpetrated by the utterly deranged -
@ity@estradiol.city ...except if you're implementing a compiler and want to support safe casts from larger to smaller kinds of integers pointed by a pointer, apparently.
-
@ity@estradiol.city ...except if you're implementing a compiler and want to support safe casts from larger to smaller kinds of integers pointed by a pointer, apparently.
-
@ity@estradiol.city Nina has explained it better than I could.
RE: https://gts.q66.moe/users/q66/statuses/01JY22XV9NX7CD856X3NE1476B -
@ity@estradiol.city Nina has explained it better than I could.
RE: https://gts.q66.moe/users/q66/statuses/01JY22XV9NX7CD856X3NE1476B -
@ity@estradiol.city Assuming you're acquainted with the concept of pointer (I hope not to insult you by thinking that you might not be), if you have a 32 bit integer in little endian encoding, like this:
It would be mapped to memory as this sequence of bytes. And if you had pointers pointing to these integers, they would point to these addresses:0x00000003
Now, if you (by mistake or on purpose) miscast theseLittle endian: Big endian: 03 00 00 00 00 00 00 03 ^ ^ int *p int *pint *pointers aschar *, what happens?
So... big endian is more legible, but little endian is more robust to miscasts.Little endian: *((char *)p) is 0x3 Big endian: *((char *)p) is 0x0 -
@ity@estradiol.city Assuming you're acquainted with the concept of pointer (I hope not to insult you by thinking that you might not be), if you have a 32 bit integer in little endian encoding, like this:
It would be mapped to memory as this sequence of bytes. And if you had pointers pointing to these integers, they would point to these addresses:0x00000003
Now, if you (by mistake or on purpose) miscast theseLittle endian: Big endian: 03 00 00 00 00 00 00 03 ^ ^ int *p int *pint *pointers aschar *, what happens?
So... big endian is more legible, but little endian is more robust to miscasts.Little endian: *((char *)p) is 0x3 Big endian: *((char *)p) is 0x0 -
@cinnamon @ity big endian turned out to have an advantage in reverse engineering. Why?
If your CPU is big endian and doesn't like unaligned access (which most of them do iirc, even if they pretend otherwise), compiler can't do smaller access, so you know the actual size of memory being read or written to, even if it needs just one byte. -
@cinnamon @ity big endian turned out to have an advantage in reverse engineering. Why?
If your CPU is big endian and doesn't like unaligned access (which most of them do iirc, even if they pretend otherwise), compiler can't do smaller access, so you know the actual size of memory being read or written to, even if it needs just one byte.@a1ba@suya.place @ity@estradiol.city Reading this post has brought memories of MS-DOS era code with "anti-disassembling protection" which had jumps to the middle of multi-byte instructions that the Borland Turbo Pascal/Turbo C couldn't disassemble because they were misaligned to the word size.
-
@a1ba@suya.place @ity@estradiol.city Reading this post has brought memories of MS-DOS era code with "anti-disassembling protection" which had jumps to the middle of multi-byte instructions that the Borland Turbo Pascal/Turbo C couldn't disassemble because they were misaligned to the word size.
-
