12 ms·

I disagree with many of the arguments. Many of them are ignoring the reality of today. One example: > If you want bytes, use unsigned char. If you want octets

• omginternets 11y ago
  What was the original distinction between bytes and octets? Byte = word vs octet = 8-bits, i.e. a byte is not necessarily 8-bits long?
  • TazeTSchnitzel 11y ago
    A byte is the smallest addressable unit. An octet is a unit of 8 bits, which is a common size for a byte.
  • caf 11y ago
    A byte is the smallest individually-addressable unit.
• EliRivers 11y ago
  Oh, well, if you haven't seen something then it must not exist. "I wasn't even told that there once were systems where this wasn't true until fairly recently." Wait, so someone filled in a piece of your ignorance and your response is still "Bytes and octets are the same"?
  • sipior 11y ago
    To be fair, what they actually said was, "Bytes and octets are the same today". It's a little disingenuous, I think, to quote everything but the last word, especially since the qualifier "today" was kind of their entire point.
    • EliRivers 11y ago
      In the words of SLJ, allow me to retort. Bytes and octets are the same today on the hardware the OP is used to working with; I'm guessing whatever the latest generation of commodity x86 derivatives is. The real crime here isn't lack of knowledge; it's thinking that one's own narrow experience is all-encompassing and that what's true in one part of the programming world is true everywhere.
      • sipior 11y ago
        I'm not disputing your last statement. I'm saying that, if you are going to quote someone, quote the whole sentence, at least, and don't leave out words that are substantial to the point they are making.
• ue_ 11y ago
  >Bytes and octets are the same today. I never came across a system where this wasn't true. The fact that all modern systems use eight bit bytes is no reason to assume that a byte is eight bits. The fact is that a byte is not eight bits large. People may wish to run code on "historical" systems, and someone may wish to create a 9-bit byte system for fun. To write C code with an assumption that things are one way, when the standard does not define this assumption, screams of unportable code. You might as well use GCC extensions - after all, for a long time, what would it matter? Everyone used GCC, right?
  • methyl 11y ago
    > People may wish to run code on "historical" systems, and someone may wish to create a 9-bit byte system for fun. I bet there will be then bigger problems with porting the code than assuming byte is 8 bit long if someone is creating a 9-bit system "for fun".
  • pcwalton 11y ago
    As a matter of fact, GCC extensions are de facto standards at this point. Clang had to copy most of them. Same with bytes not being 8 bits. Nobody will ever make a system where that's not the case anymore. You'd break de facto compatibility with almost all C code for no reason. Market realities trump making systems "for fun".
    • ue_ 11y ago
      >You'd break de facto compatibility with almost all C code for no reason. The authors of that code should have written portable code if they didn't want it to break.
      • mondoshawan 11y ago
        Texhnically, they did. The go to compiler for years was GCC, with all the GNU extensions turned on. The problem is that those extensions were classically on by default, so it was very easy to just use them without thinking too much about it.
• XorNot 11y ago
  Yeah at least since the 80s bytes has been taught as "8 bits" for as long as I've ever heard it. That said, uint8_t is more explicit (and less to write).
• JoachimSchipper 11y ago
  char is apparently still not always 8-bit on current DSP chips, where everything is 32-bit. Historically, PDP-8's used 12-bit bytes and Crays also used 32-bit bytes. (EDIT: fixed PDP-11 -> PDP-8, thanks kabdib!)
  • kabdib 11y ago
    PDP-11s always used 8-bit bytes, you're probably thinking of the PDP-8. I don't remember what the popular sizes for the PDP-10 were. A 36-bit machine, none of the choices were really great. (I know that CLU on the PDP-10 used 36 bits).
• nabla9 11y ago
  Just one counterexample: Texas instrument C28x core is 16-bit addressable. Each byte is 16 bits. >The TMS320C28x byte is 16 Bits. By ANSI/ISO C definition, the sizeof operator yields the number of bytes required to store an object. ANSI/ISO further stipulates that when sizeof is applied to char, the result is 1. Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits. http://processors.wiki.ti.com/index.php/Byte_Accesses_with_the_C28x_CPU http://processors.wiki.ti.com/index.php/Byte_Accesses_with_t... C is the closest thing to universally portable assembler.
  • pjmlp 11y ago
    I fail to see how C is more portable than any other memory safe systems programming language, other than having the fortune that for 30 years OS and hardware vendors decided to only support C compilers.
    • nabla9 11y ago
      Compilers. Compilers for everything. You can hype your favorite systems language all you want, but if there is no compiler, it wont compile. >OS and hardware vendors decided to only support C compilers. If you want your favorite language X to work everywhere C does. Just make X-to-C compiler.
      • dietrichepp 11y ago
        X-to-C compiler isn't as nice as it could be, because you're writing code for some weird chip and need to twiddle some bits for IO using a macro defined in a header somewhere, and that doesn't play nicely with your pet X-to-C compiler. Not an ideal situation, for sure, but a real one.
        • nabla9 11y ago
          It's possible for translator understand headers and macros and generate bindings for them. Even for function macros. For example, GNAT has macro binding although it's not complete. Btw. There is nothing "pet" in X to C translators. You pay good money for a good Ada to C compiler.
• mfukar 11y ago
  > Bytes and octets are the same today. Not in DSPs. Today.
• notalaser 11y ago
  Hi, I'm working on one. It's a recent DSP with pretty massive processing power that's powering some really, really expensive machines (six figures a piece). A byte is 32 bits here. This is common on a lot of VLIW machines. I guess uint8_t et co. appeared out of the plight of many systems programmer who needed to do things like "hand these precisely 8 bits to this peripheral". On this machine, getting only these specific 8 bits out of a char requires bit twiddling trickery (it doesn't support unaligned memory access), but if the peripheral you're talking to (e.g. a temperature sensor) calls 8 bits a byte, you're going to have to send it 8 bits, not teach it that a byte doesn't always mean 8 bits. Prior to stdint.h (and on any platform without a C99-enable compiler, which are neither few nor unused), we used to work around this crap with a bunch of custom macros defined in hardware-specific header files. It was a mess and you needed to learn a lot more about every specific platform's compiler than you ever cared about. And it was particularly beautiful on bi-endian platforms, oh yes, those were so beautiful. C99 came and said you know what, this is so platform-and-compiler-specific that the compiler should worry about it and that accounted for a massive relief of about 20% of my daily stress dose. You should use it when you know that you need something to be exactly 8 bits long. Which may or may not be a byte (that's why it frickin' says int8_t and uint8_t, not byte and ubyte). Edit: I'm going to piggyback on my comment and gently ask anyone to consider not blindly following the advice to inline the declaration of b in code like this: void test(uint8_t input) { uint32_t b; if (input > 3) { return; } b = input; } In many (most?) cases, that's good advice, but declaring it (and any other local variables) in the beginning has the major advantage of allowing me to read the first line of the functions and tell how much space is being allocated on the stack when the function is called. This is not only nice to know for performance reasons, it's also useful information for platforms that have limited stack size or -- my favourite! -- platforms that lack a MMU, so when your stack runs into useful data, your system doesn't crash, it just starts acting funny.
• rkangel 11y ago
  The XAP processor architecture use in CSR Bluetooth Chips (design orginally from Cambridge Consultants) is one such processor. On it: A 'byte' is 16 bits. A word is 16 bits (so sizeof(int) == 1) A function ptr is 24 bits (so sizeof(Fx) == 2) CSR have sold well over a billions chips. There is a strong argument that this is the 3rd most popular architecture family after ARM and X86/64. Things that x86 programmers do that won't work because they make assumptions the C standard doesn't specify: Cast a uint16_t* to uint8_t* to extract the upper and lower octets of the uint16 (a uint8_t array is actually in memory a uint16_t array using only the lower 8 bits) Store a function pointer in a void* (throws away upper 8 bits of the 24 bit func pointer).
  • Roboprog 11y ago
    Would you port x86 code, like say the Apache web server, to this chip? Or is it basically a memory constrained little device that you are writing a driver for, from scratch? Seems like you would learn the rules, even though they are a bit odd, easily enough while writing something from scratch, or maintaining an existing (somewhat) small driver program. Agreed, though, be aware (or just beware?) that this chip is quite different, and new skills MUST be learned.