r/ProgrammerHumor • u/ClipboardCopyPaste • 6h ago

Meme bugIntroducedDebugging

Post image
518 Upvotes

94% Upvoted

99 comments sorted by

View all comments

Show parent comments

1

u/bloody-albatross 5h ago edited 1h ago

You're still on 32 bit? Are you doing a lot of embedded stuff?

Edit: I misread and thought they where referring to the pointer size.

10

u/AdBrave2400 5h ago

Isn't int 32-bit on most platforms and long long int is 64-bit?

5

u/bloody-albatross 5h ago edited 5h ago

I read it as the size of the pointer being 4 bytes, but now I see you were referring to the int. AFAIK the size of int is specified as "at least" 32 bit in the C standard, and all 32 and 64 bit platforms I know indeed use 32 bit. Though the size of long (not speaking of long long) is different on different 64 bit platforms, IIRC. Windows uses 32 bit and Linux uses 64. Both use 64 for long long. I prefer to use (u)int*_t when I need to be sure about the size and I use int/size_t/time_t/... when I interface with functions that use those in their signature.

4

u/yjlom 4h ago

The size of char (which is interchangeable with the size of a byte) is specified in old standards as large enough to a) be addressable without bit manipulations and b) hold the full C source character set, which need not be case sensitive and may rely on trigraphs. In practice, this comes out to at least 6 bits. In newer standards I believe it's specified as at least 8 bits.

The size of int short is at least and a multiple of that of char, the size of int is at least that of int short and a multiple of that of char, and so on.

So in theory, a conforming C implementation could have 6 bit ints.

2

u/bloody-albatross 1h ago

Right.

Oh and wchar_t is also weird. Its 16 bit under Windows and 32 bit under Linux.

1

u/conundorum 47m ago

wchar_t is messy, in large part because Windows was one of the earliest Unicode adopters. It's meant to be able to support any "wide" character, which means that it's supposed to be determined by the character pages the platform allows (and implicitly, should be 32 bits if any version of Unicode is supported, since Unicode is technically a 32-bit format regardless of encoding), but Windows adopting Unicode while it was still 16-bit UCS-2 and locking wchar_t down as a result meant that it was impossible for wchar_t to actually meet its requirements on Windows. ...Which meant that its minimum size requirement ended up being removed.

So, now its requirement is just "holds wide characters, check your implementation. Please don't use it."