It says it there on the page: "It depends on OS by OS but, most commonly…"

It also varies from one compiler to another, and on a few different versions on the same compiler. It also varies on the same OS, same compiler but different target architecture.

And that's now. Who knows if it won't vary due to compiler optimizations in the future? It is wrong to rely on anything more than what it says on the standard.

> You can not rely on any further information about them.

Not entirely true. One may assume that sizeof(short) <= sizeof(int) <= sizeof(long). In particular, one may cast from short to int and back without loss of information, and likewise from short to long and from int to long.

You can't even rely on that...

long --> 4 bytes in 32 bit builds everywhere I've used.

long --> 4 bytes in 64 bit builds on windows and OS/400, 8 bytes in almost all 64 bit builds on UNIXs that I've used (HPUX,Solaris,Linux,AIX).

In marcosdumay's comment, those were greater-than-or-equals, not arrows.

char is 1 byte exactly.

A char is 1 byte on most systems, but the actual standard defines it as having CHAR_BITS number of bits. Modern C defines CHAR_BITS as CHAR_BITS >= 8. Some older machines have 7 bits. Theres nothing stopping machines from changing what CHAR_BITS is.

<Limits.h>

People are talking past each other. In the C standard ‘byte’ means minimum addressable unit — the unit of sizeof — which need not be exactly 8 bits (but in ANSI C must be at least 8 bits). In C, 'char' is one byte, always and exactly. It's also possible for 'long' to be one byte, provided CHAR_BIT≥32.

> In the C standard ‘byte’ means minimum addressable unit — the unit of sizeof

Do you have a reference? I've always seen a byte defined as 8 bits. No matter what. (Unless you're talking to a hard drive manufacturer, that's a different bucket of worms though.)

The draft ISO/IEC 9899:201x PDF of "Programming Languages — C" says:

"3.5 bit

unit of data storage in the execution environment large enough to hold an object that may have one of two values

NOTE It need not be possible to express the address of each individual bit of an object.

3.6 byte

addressable unit of data storage large enough to hold any member of the basic character set of the execution environment

NOTE 1 It is possible to express the address of each individual byte of an object uniquely.

NOTE 2 A byte is composed of a contiguous sequence of bits, the number of which is implementation-defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit."

I can't find any indication that a byte is the minimum addressable unit. I guess that is because of 4-bit CPUs and/or CPUs that can address individual bits.

It also uses "byte" very sparingly, most of the time in the context of multibyte (not hyphenated) to single-byte (hyphenated) conversions, but also in section 5.2.1:

"The representation of each member of the source and execution basic character sets shall fit in a byte."

And there also is a guarantee that a unsigned char is as large as a byte in a footnote to section 6.2.6.1:

"A byte contains CHAR_BIT bits, and the values of type unsigned char range from 0 to 2^CHAR_BIT − 1"

I doubt that char and unsinged char can be of different size, but didn't check that.

Orginally? See §7.4 of Planning a Computer System: Project Stretch, edited by Werner Buchholz who coined the term. http://archive.computerhistory.org/resources/text/IBM/Stretc...

For C, see C11 §3.6: “byte — addressable unit of data storage large enough to hold any member of the basic character set of the execution environment” http://www.iso-9899.info/n1570.html#3.6

Makes sense now. Thanks

(From the C99 standard:)

§ 6.5.3.4 The sizeof operator

[…]

Semantics

2 The sizeof operator yields the size (in bytes) of its operand,

[…]

3 When applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1.

I was about to jump in and say "no it's not!" but I see several people have pointed out that the C Standard of all things says bytes don't necessarily have 8 bits. Wow!

What I'd like to know is, how common are non-8-bit-byte CPUs these days, for new devices?

I worked with Texas Instruments C54x and C55x DSPs back in the early 2000s (https://en.wikipedia.org/wiki/Texas_Instruments_TMS320#C5000...). They had 16-bit chars and that was incredibly annoying -- very few low-level third-party libraries would even compile properly. Are those still used?

It seems like everything has an ARM chip on the side these days, so maybe (hopefully) there's less need to run application code on bizarre DSPs. Except for those unsung heroes maintaining old set-top boxes and the like.

More accurately, sizeof(char) is always 1. This is simply because sizeof returns the size of the object measured in terms of the equivalent number of chars (rather than 'bytes').

Perhaps your notion of what a byte is different, but according to the C99 standard:

- sizeof returns size in bytes;

- sizeof (char) == 1;

- one byte has CHAR_BIT bits;

- CHAR_BIT >= 8.

> - one byte has CHAR_BIT bits;

Can you link a reference to this? Seems backwards/weird.

So per C99, a byte can have more than 8 bits? My mind boggles...

For 36-bit CPUs, the 9-bit byte was a natural choice (as was storing 6 characters of a more limited character set in a 36-bit word)

Ah, yes, 36-bit. I had forgotten about that, despite my mother having worked on such systems.

That's not true. sizeof(char) returns 1 because the size of a char in that implementation is 1 byte and C doesn't directly address bits.

Well, according to the Wikipedia article about sizeof,

In the programming languages C and C++, the unary operator sizeof generates the size of a variable or datatype, measured in the number of char size storage units required for the type. As such, the construct sizeof (char) is guaranteed to be 1.

I stand corrected.

You were correct after all. The C99 standard does indeed talk about sizeof in terms of bytes!

I guess this is one of those few times that we can say we were both correct.

Anybody who cares about integer sizes in any more detail needs to use things like int32_t.