7 ms·

Actually, since C99, sizeof char is defined to be 1 (byte). The number of bits in a byte is implementation-defined. However, "it's implementation specific and

• ohyoutravel 10y ago
  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.
  • eps 10y ago
    sizeof(char) is indeed 1. It's the CHAR_BIT that fluctuates (and we have a Cray compiler to prove it).
    • ori_b 10y ago
      Note that POSIX defines CHAR_BIT as 8.
  • plorkyeran 10y ago
    sizeof(char) is inherently 1 because sizeof()'s unit is chars, not bits or bytes.
• jsjohnst 10y ago
  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.
• breadbox 10y ago
  Minor point: sizeof(char) was defined to be 1 even in the original C89. "char" has always been a misspelling of "byte" in C.
  • mark-r 10y ago
    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.
    • lmm 10y ago
      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.
      • qb45 10y ago
        What optimization opportunities does it give?
        • zlynx 10y ago
          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.
          • qb45 10y ago
            > 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.
  • swolchok 10y ago
    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).
• jcoffland 10y ago
  Better yet, write a test program and check the answer yourself.
• greenshackle2 10y ago
  > 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.)
  • mayoff 10y ago
    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.
    • dottrap 10y ago
      >> 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 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.)
      • slededit 10y ago
        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++.
      • 10y ago
• gens 10y ago
  >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)
  • sharkbot 10y ago
    > 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.
    • gens 10y ago
      Yes, was just about to correct myself, sizeof(char) is always 1. Nevermind me.
  • rcfox 10y ago
    > 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.
• yes_or_gnome 10y ago
  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.
  • kps 10y ago
    I've also personally encountered 24 for C. That's not the problem with (' '*13) here, though — C doesn't mandate ASCII.
    • ekiru 10y ago
      char is also allowed to be a signed type, in which case overflow is undefined behavior.
      • evincarofautumn 10y ago
        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.
  • qb45 10y ago
    > 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".
• namename 10y ago
  yeah
• krylon 10y ago
  > 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.