6 ms·

>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

by 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.
    - pjmlp 11y ago
      On GNU/Linux, yes. Outside world, there are tons of C compilers to chose from.
  - lmm 11y ago
    If a few people write unportable code in your language, they're bad programmers. But if everyone writes unportable code in your language, it's a bad language.
  - pcwalton 11y ago
    If you're designing a new ISA, it's extremely difficult to succeed in the market no matter what you do. But one excellent way to guarantee you won't succeed is to have that attitude toward your developers.
lultimouomo 11y ago
By the same argument we shouldn't assume that bits have only two values - what, you mean I can't write C for my ternary logic computer? You need to make a decision about which simplifying assumptions you make - C has decided not to assume there are 8 bits to the byte. I think it's arguable that in 2016 this is not the best decision, and they could get rid of some cognitive overhead by making the simplifying assumption.
- dietrichepp 11y ago
  Unfortunately, there are real world systems with C compilers that do not have 8 bit bytes. It's easy to forget the embedded world. C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever. Bit, however, means "binary digit". That's the literal definition of the word. Historical usage of the word "byte" has varied.
  - lultimouomo 11y ago
    > C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever. I'm not an expert on DSP processing in any way, but I'd argue that if the environment is so peculiar that it doesn't have 8-bit bytes, you won't be able to use so many of the (formally optional) parts of C that you might as well call your code "weirdC" and do without char. It's not like you're going to use normal C libraries, and you are most probably relying on a specific compiler implementation and a lot of platform specific weirdnesses.
    - dietrichepp 11y ago
      I think you're underestimating the amount of legacy code that people have. We're not talking about "I have a new processor, let's write code for it." That's unrealistic. It's more like, "I have a new processor, let's get our existing code base working on it, because if we don't, we're going to lose millions of dollars."
whyever 11y ago
I would be very surprised if some non-trivial C code written for x86 compiles and runs unmodified on exotic platforms. Besides, I don't want to be hold back by people wishing to run code on historical or experimental systems.

by ue_ 11y ago

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.
  - pjmlp 11y ago
    On GNU/Linux, yes. Outside world, there are tons of C compilers to chose from.
- lmm 11y ago
  If a few people write unportable code in your language, they're bad programmers. But if everyone writes unportable code in your language, it's a bad language.
- pcwalton 11y ago
  If you're designing a new ISA, it's extremely difficult to succeed in the market no matter what you do. But one excellent way to guarantee you won't succeed is to have that attitude toward your developers.

lultimouomo 11y ago

By the same argument we shouldn't assume that bits have only two values - what, you mean I can't write C for my ternary logic computer? You need to make a decision about which simplifying assumptions you make - C has decided not to assume there are 8 bits to the byte. I think it's arguable that in 2016 this is not the best decision, and they could get rid of some cognitive overhead by making the simplifying assumption.

dietrichepp 11y ago
Unfortunately, there are real world systems with C compilers that do not have 8 bit bytes. It's easy to forget the embedded world. C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever. Bit, however, means "binary digit". That's the literal definition of the word. Historical usage of the word "byte" has varied.
- lultimouomo 11y ago
  > C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever. I'm not an expert on DSP processing in any way, but I'd argue that if the environment is so peculiar that it doesn't have 8-bit bytes, you won't be able to use so many of the (formally optional) parts of C that you might as well call your code "weirdC" and do without char. It's not like you're going to use normal C libraries, and you are most probably relying on a specific compiler implementation and a lot of platform specific weirdnesses.
  - dietrichepp 11y ago
    I think you're underestimating the amount of legacy code that people have. We're not talking about "I have a new processor, let's write code for it." That's unrealistic. It's more like, "I have a new processor, let's get our existing code base working on it, because if we don't, we're going to lose millions of dollars."

whyever 11y ago

I would be very surprised if some non-trivial C code written for x86 compiles and runs unmodified on exotic platforms. Besides, I don't want to be hold back by people wishing to run code on historical or experimental systems.