Yes, but the term "byte" doesn't tell you much. Most people assume that a byte is 8-bits which isn't true. If the definition the of `char` was `1 octet`, then you could make safer assumptions about "What's the result of `' ' * 13`?".

From ISO/IEC 9899:2011:

  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.

Edit: Reading further into the C11 spec, `5.2.4.2.1 Sizes of integer types <limits.h>`, it says that `CHAR_BIT` must be 8 bits (or larger). A google search suggests there exists some processors that have 16-bit bytes and others that have 32-bit bytes.

I've also personally encountered 24 for C. That's not the problem with (' '*13) here, though — C doesn't mandate ASCII.

char is also allowed to be a signed type, in which case overflow is undefined behavior.

It’s not because of the signedness of char—not only do character literals have type int, but even if this weren’t a literal, the char would be promoted to (signed) int before the multiplication. But of course the multiplication of two ints can still overflow.

> Most people assume that a byte is 8-bits which isn't true.

It is worth remembering that POSIX (and Windows probably too) mandate 8bit chars so there is no point being defensive about it on these particular platforms. And I kid you not, I have seen people who are. Because "ISO C99 this and that".

> read the standard

Casey Muratori, who's a better C programmer than me, is of the opinion that you should check your compiler's behavior rather than read standards.

(Not that you should take his word as gospel, I don't fully agree myself, but it's worth considering.)

The problem with this idea is that, if you're relying on undefined behavior and don't know it, your compiler's behavior might change depending (at a minimum) on the code you use in production but not in your test case and depending on the compiler version.

It's much better to avoid undefined behavior entirely. The problem with this idea is that it's hard to learn and remember all the different kinds of undefined behavior.

>> read the standard

>> Casey Muratori, who's a better C programmer than me, is of the opinion that you should check your compiler's behavior rather than read standards.

In Casey Muratori's case, he's the type of person who cares to understand what the compiler is actually generating under the hood. He doesn't exactly trust the compiler to always do the right thing.

There was an episode of Handmade Hero where he caught an optimization #fail of the compiler and tried to figure out what was going on (live). https://twitter.com/cmuratori/status/596775025023287297

Casey Muratori also has been developing in Visual Studio for a very long time. Visual Studio has a long, tortuous, history of being non-stanards compliant and buggy. And Microsoft until very recently, never cared to fix anything. (And it still doesn't conform to C99, let alone C11.)

Microsoft already stated multiple times that the focus of Visual C++ is C++ (hence the name).

Whatever C related updates you might see, are the ones required by the ANSI C++ for C compatibility.

For C99 and C11 support there is the clang frontend to C2, the Visual C++ backend, currently taking an LLVM role at Microsoft, being shared between clang, VC++ and .NET Native.

The Visual C compiler is only for backwards compatibility. If you are looking for improved C compilation you'll be waiting a very long time. The only improvements they've made were those also required for C++.

So, how exactly do you check your compiler's behavior?

Given: 1) There are various optimizations that may kick in or not depending on UB. 2) The cleverness of the optimizer may and does(!) change between versions. 3) There's no "-warn-on-optimizer-changes" flag for any compiler.

Do you think it's realistic to compare compiler output whenever you upgrade your compiler? Do you think it's realistic for 1M SLoC projects? If not, do you take a statistical approach with random sampling? If so, I'd be very interested. If not... what exactly are you sure of and how?

> is of the opinion that you should check your compiler's behavior rather than read standards

Do both.

Disassemble your compiler's output to see what horrors the optimizer inflicted on your code to "break" it. Read the standard to understand why it thought it was an okay optimization to do in your case, to avoid running afoul of the same mistake again. Ask what other optimizations are enabled by this undefined behavior, the better to spot them when the code your coworker's former boss's roomate, who interned for a month or two, invokes undefined behavior.

Repeat.

(To be fair, I haven't read the standards cover to cover - perhaps I should, I'm still occasionally learning about new and exciting forms of UB...)

> you should check your compiler's behavior

There is one thing I have noticed in gcc and clang which is done against the standards: The sign of bit sized int in a struct.

eg: In a struct with member 'int a:8', The standard says that 'a' can be signed or unsigned (based on the machines default of the sign of char). But In gcc and clang, this is signed always regardless of the machine.

Similarly, msvc guarantees signed overflow, it's not UB when targeting only that compiler. And gcc/clang have a compiler switch to do the same, I believe. Those things are probably what they meant when they said to look at what the compiler does.

> eg: In a struct with member 'int a:8', The standard says that 'a' can be signed or unsigned (based on the machines default of the sign of char). But In gcc and clang, this is signed always regardless of the machine.

Wait, are you saying gcc/clang's behaviour is permitted by the standard, or not?

> Wait, are you saying gcc/clang's behaviour is permitted by the standard, or not?

It's permitted. The same way as a char can be signed or unsigned: Implementation defined. But in this case, it's always signed regardless of the architecture (against how a char is handled).

From c99 draft (n1570), J.3.9 (Implementation-defined behavior): Whether a ‘‘plain’’ int bit-field is treated as a signed int bit-field or as an unsigned int bit-field (6.7.2, 6.7.2.1).

But say, another compiler (ARM compiler) treats this differently [0]: Untill version 5 of the compiler, such an int was unsigned by default. Later versions defaulted to signed (as do gcc/clang).

[0] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....

For the record, I disagree with this. You only need to check the implementation if you're straying from the standard or the compiler is. Neither should be... standard.

Exactly. I immediately thought "implementation specific" on the first question but then didn't see that as an option. By the second question, I had caught on that 'D' was the intended answer throughout.

Minor point: sizeof(char) was defined to be 1 even in the original C89. "char" has always been a misspelling of "byte" in C.

sizeof(char) has to be 1, but char doesn't have to be 1 byte in size. It's more correct to say that sizeof(foo) returns a result relative to sizeof(char).

> but char doesn't have to be 1 byte in size

It is, but not required to be an octect. Quoting from the standard (n1570, 3.6):

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

Later in a comment (page 44 in pdf, note 49): A byte contains CHAR_BIT bits

char doesn't have to be 8 bits in size, true, but C basically doesn't give you any way to address memory smaller than a char.

> C basically doesn't give you any way to address memory smaller than a char

It does, via bit-fields.

Or via the bitwise operators. Still, it is not possible to take the address of a bitfield.

The difference may be 100% semantics, but when I am using a bit field, I am addressing the particular bits I am interested in via a name, and when I am shifting and masking bits, I am directly manipulating a piece of memory until its value represents the bits that I am interested in.

I prefer to think of "byte" as unsigned. Although I've never quite figured out why char is signed on most implementations, it would most naturally be unsigned too.

I suspect because signed has more undefined behaviour. C compilers will always choose the option that gives them most optimization freedom since that's what they're judged on.

What optimization opportunities does it give?

Add 128 to a signed char and the compiler is free to assume it is zero/false (because undefined behavior) OR assume the value is always greater than 127 (because undefined behavior). Or if it compiles it into machine code, the result may depend on register width since it may or may not store it back into memory. Resulting in a value either larger than 127 or mod 128 depending on register pressure since the compiler isn't obligated to AND 0xFF because Undefined Behavior.

> Add 128 to a signed char and the compiler is free to assume it is zero/false

To be honest, I hope compilers don't do such things. I would vastly prefer to see it run Tower of Hanoi simulation in Emacs at this point.

But evading bound-checking of 8bit math done in 32bit registers is totally reasonable (by the standard of usual UB optimizations), thanks.

>Actually, since C99, sizeof char is defined to be 1 (byte). The number of bits in a byte is implementation-defined.

(edit: i misread, it's always 1) To be pedantic, a size of char is defined by CHAR_BIT in limits.h. As well as all of the min and max values and lengths in bits for integers.

To add to the discussion, many high level languages don't have a hard min and max values (haskell, that is popular in these woods, i see has minBound/maxBound).

From the "So you think you know C?" test i answered... probably correct for the "standard" x86 implementation, while knowing that they are implementation specific (for 4 i'm not sure). The authors "Don't know" is his own, i would have answered the questions as "It depends", but that was not offered.

In the end i agree with the general notion here, that this is ugly C.

PS Integer wrapping is undefined as well, so "good" C code should work around it. (i miss this from assembly)

> To be pedantic, a size of char is defined by CHAR_BIT in limits.h. As well as all of the min and max values and lengths in bits for integers.

To be even more pedantic: it's the number of bits in a char that is defined by CHAR_BIT. However, sizeof returns the number of chars needed to store a type, where sizeof(char) is defined to be 1.

Yes, was just about to correct myself, sizeof(char) is always 1.

Nevermind me.

> PS Integer wrapping is undefined as well, so "good" C code should work around it.

Signed integer overflow is undefined. Unsigned integer overflow is defined.

> Actually, since C99, sizeof char is defined to be 1 (byte). The number of bits in a byte is implementation-defined.

Ever since, reading introductions to C that say things like "a char is usually one byte in size" make me cringe. I never bothered to check, though, what C89/C90 had to say on this.

Is this true? I thought the C99 standard just specified that the guaranteed minimum size is 1 byte. I've been using CHAR_BIT to define this.

sizeof(char) is indeed 1. It's the CHAR_BIT that fluctuates (and we have a Cray compiler to prove it).

Note that POSIX defines CHAR_BIT as 8.

sizeof(char) is inherently 1 because sizeof()'s unit is chars, not bits or bytes.

Better yet, write a test program and check the answer yourself.

yeah