Hacker News Reader

Comment by petke | Hacker News Reader

> 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/CppC...

View on HN

> 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.

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.

You argue if GCC and MSVC document their current undefined behaviour, they are creating new languages?

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.

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.

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.

> 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-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.

Programming languages necessarily have stricter definitions and semantics than human languages.

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?

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.

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.)

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?

Reply on news.ycombinator.com