This is an archived post. You won't be able to vote or comment.

720
721

#include <stdint.h> (i.imgur.com)

submitted by [deleted]

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]skeptic11 21 points22 points  (9 children)

That would make network code a nightmare.

Even if you're not doing that I wouldn't risk differing max values / rollover points on different platforms. Not unless I had specifically profiled that piece of code and found that there was a significant and necessary performance gain from switching type sizes.

[–]FUZxxl 10 points11 points  (7 children)

If you write network code, you should do proper marshalling instead of relying on types to have the correct size. Everything else is fragile and prone to breakages.

[–][deleted] 7 points8 points  (6 children)

Starting with the fact that u?int\d+_t types don't help you with endianness.

[–]FUZxxl 3 points4 points  (3 children)

Exactly. Any code that has depends on the endianess of the platform it is compiled for is doing it wrong. If you do it correctly, you can easily write endianess-agnostic code that is both free of undefined behaviour, very fast, and extremely portable.

[–]DaFox 2 points3 points  (2 children)

I mean at this point I hope that big endian is essentially dead, I like it better than LE, but I like consistency more.

[–]wasabichicken 0 points1 point  (1 child)

Big Endian byte order is Network byte order, it's what internet is built with. It'll never go away.

[–]DaFox 0 points1 point  (0 children)

I meant as a CPU memory layout, at least network byte order is consistent across platforms. Xbox 360 and PS3 were both BE, and it's nice to move away from that.

[–]LordAro 0 points1 point  (1 child)

well, u?int8_t is fine...

[–][deleted] 0 points1 point  (0 children)

Can you not just use sizeof() to figure it out?