5 ms·

> I'd like to see a free C compiler that clearly defines, and permanently commits to, carefully designed semantics for everything that's labelled "undefined" or

by petke 11y ago

> I'd like to see a free C compiler that clearly defines, and permanently commits to, carefully designed semantics for everything that's labelled "undefined" or "unspecified" or "implementation-defined" in the C "standard". That wouldn't just be a new compiler. That would be a new language. I dont think there are any short cuts to fix C. C++ is doing something somewhat similar with the "C++ Core Guideline" rules, which are designed to be checkable by static analysis tool. The long term goal is that eventually C++ will become a safe subset, when all the error-prone parts of the language have replacements. > "Following the rules will lead to code that is statically type safe, has no resource leaks, and catches many more programming logic errors than is common in code today. And it will run fast - you can afford to do things right." https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

geocar 11y ago
> That would be a new language I don't see why it wouldn't be a valid implementation of C by simply defining things that C doesn't fully define. There's nothing about the definition of "undefined behaviour" that prevents you from defining it in your implementation.
- steveklabnik 11y ago
  Because then you are relying on a specification that's not in the spec. A different interpretation means that your code no longer works. Therefore, you've effectively created a new language.
  - geocar 11y ago
    You argue if GCC and MSVC document their current undefined behaviour, they are creating new languages?
    - steveklabnik 11y ago
      Not if they document it. But if you write a program that relies on those behaviors, you don't have C anymore, you have "GCC-C" or "MSVC-C". I'm also not saying that's inherently a bad thing.
      - geocar 11y ago
        Then we already have those languages: They exist because they are used. I'm not sure this is helpful though. We've accepted "literally" also means "not literally" without creating a new language.
        steveklabnik 11y ago
        Yes, but that introduces some backwards incompatibility. The C standards body has a really, really high bar for doing so. English, not so much. That is a choice they're making.
        kenko 11y ago
        > I'm not sure this is helpful though. We've accepted "literally" also means "not literally" without creating a new language. http://waste.typepad.com/waste/2014/07/on-a-popular-misconception-concerning-literally.html http://waste.typepad.com/waste/2014/07/on-a-popular-misconce... It's just a figurative use of "literally". It's like saying "He's such a baby" of an immature (<- also figurative!) adult. You aren't saying that such an adult is actually a baby.
        scott_s 11y ago
        Programming languages necessarily have stricter definitions and semantics than human languages.
  - quotemstr 11y ago
    Sixth grader students know all the words third grader students know, but third grade students do not know all the words that sixth grade students know. Are the third and sixth grade students speaking different languages?
    - steveklabnik 11y ago
      In a certain sense, yes. Sixth graders can say things that third graders cannot understand. The trick is to try to bring together all of these dialects in a way that everyone can in fact understand. This is why writing language specifications is _hard_. And even afterwards, you can still choose a dialect over the standard. You'll just lose a certain segment of your audience. That may or may not matter for your purposes.
- scott_s 11y ago
  It would be a valid implementation of C. But if you want to depend on the new behavior, which was previously undefined, then you would have to reference this new specification. That effectively makes it a new language, because you would no longer reference the C specification, but this new one. (And if you don't want to depend on the new behavior, which was previously undefined, then there's not much point in using this particular implementation.)
- petke 11y ago
  The C standard allows for many different compiler implementations. Say you set in stone and publish to your users, a certain implementation specification. You have now created a new spec. Really a new language. Your users will make programs that rely on this new specification. Such code will no longer be portable to other standard C-compilers. Their programs might only be well defined in your new language, not in standard C. For instance he talks about a C that default initializes all memory to zero. A program that relies on that will no longer be portable to other C compilers. If its no longer portable, is it really the same language any more?

by petke 11y ago

geocar 11y ago

> That would be a new language I don't see why it wouldn't be a valid implementation of C by simply defining things that C doesn't fully define. There's nothing about the definition of "undefined behaviour" that prevents you from defining it in your implementation.

steveklabnik 11y ago
Because then you are relying on a specification that's not in the spec. A different interpretation means that your code no longer works. Therefore, you've effectively created a new language.
- geocar 11y ago
  You argue if GCC and MSVC document their current undefined behaviour, they are creating new languages?
  - steveklabnik 11y ago
    Not if they document it. But if you write a program that relies on those behaviors, you don't have C anymore, you have "GCC-C" or "MSVC-C". I'm also not saying that's inherently a bad thing.
    - geocar 11y ago
      Then we already have those languages: They exist because they are used. I'm not sure this is helpful though. We've accepted "literally" also means "not literally" without creating a new language.
      - steveklabnik 11y ago
        Yes, but that introduces some backwards incompatibility. The C standards body has a really, really high bar for doing so. English, not so much. That is a choice they're making.
      - kenko 11y ago
        > I'm not sure this is helpful though. We've accepted "literally" also means "not literally" without creating a new language. http://waste.typepad.com/waste/2014/07/on-a-popular-misconception-concerning-literally.html http://waste.typepad.com/waste/2014/07/on-a-popular-misconce... It's just a figurative use of "literally". It's like saying "He's such a baby" of an immature (<- also figurative!) adult. You aren't saying that such an adult is actually a baby.
      - scott_s 11y ago
        Programming languages necessarily have stricter definitions and semantics than human languages.
- quotemstr 11y ago
  Sixth grader students know all the words third grader students know, but third grade students do not know all the words that sixth grade students know. Are the third and sixth grade students speaking different languages?
  - steveklabnik 11y ago
    In a certain sense, yes. Sixth graders can say things that third graders cannot understand. The trick is to try to bring together all of these dialects in a way that everyone can in fact understand. This is why writing language specifications is _hard_. And even afterwards, you can still choose a dialect over the standard. You'll just lose a certain segment of your audience. That may or may not matter for your purposes.
scott_s 11y ago
It would be a valid implementation of C. But if you want to depend on the new behavior, which was previously undefined, then you would have to reference this new specification. That effectively makes it a new language, because you would no longer reference the C specification, but this new one. (And if you don't want to depend on the new behavior, which was previously undefined, then there's not much point in using this particular implementation.)
petke 11y ago
The C standard allows for many different compiler implementations. Say you set in stone and publish to your users, a certain implementation specification. You have now created a new spec. Really a new language. Your users will make programs that rely on this new specification. Such code will no longer be portable to other standard C-compilers. Their programs might only be well defined in your new language, not in standard C. For instance he talks about a C that default initializes all memory to zero. A program that relies on that will no longer be portable to other C compilers. If its no longer portable, is it really the same language any more?