Hacker News Reader

Comment by ryukoposting | Hacker News Reader

> This seems totally misconceived to me as a basis for standardizing a language in 2022. You are optimizing for the few at the expense of the many.

Sure, but it's the same line of reasoning that made C relevant in the first place, and keeps it relevant today - some library your dad wrote for a PDP-whatever is still usable today on your laptop running Windows 10.

Because it's antiquated, it's also extremely easy to support, and to port to new and/or exotic platforms.

View on HN

The library my dad wrote (lol) for the PDP-11 is probably full of undefined behaviour and won't work now that optimizers are using any gap in the standard to miscompile code.

What a useless and jaded assumption that code written in the past is bad.

The assumption being made here is "any useful C program relies on undefined behavior" which is pretty much true.

Yes and I'm sure it's doubly true of code that was written before the C standards were written.

That sounds like a strong take - to you have examples?

Compiling with -Wall -Werror is pretty much standard those days.

-Wall -Werror is mostly designed to catch dangerous but totally well-defined idioms, not UB. It doesn't warn on every signed arithmetic operation or unchecked array access, for example.

See "useful" — it may not be not quite as strong as you're thinking. It may be possible to write a minimal C program without UB, but I'm thinking of larger programs, more than a few hundred lines. Common UB includes: array access out of bounds, dereferencing a null pointer, use after free, use of uninitialized variables. -Wall -Werror can catch some instances of some types of UB, and runtime libraries like UBSan can catch more. But they're not exhaustive.

I certainly didn't say it was bad. Just that it went outside the boundaries of a standard that was written 25 years later.

> using any gap in the standard to miscompile code

For code to be miscompiled, there has to be a definition of what correctly compiling it would mean, and if there were, it would not be undefined behavior.

Instead of "miscompiled" you can read "Doesn't do what it did on the PDP-11 with the compilers of the time".

Yeah, but if that definition is constantly shifting, you cannot expect it to work with existing codebases.

Well yeah — therein lies the problem with a language with pervasive undefined behavior.

The standard doesn't do that often, but it does sometimes. E.g. realloc to null which was previously defined, and is now UB :(

We are taking about code written before the standard so every bit of UB in the standard is in play here.

Eg the fact that overflowing a signed int can cause the compiler to go amuck would certainly be a surprise to the person who wrote code for the PDP-11.

> PDP-whatever is still usable today on your laptop running Windows 10

No, it isn't. Go on. Go ahead and try

See it break in a million weird ways. (Or, for a start, it will have the K&R C format, which is a pain to maintain)

"If your computer doesn't have 8-bit bytes" at this day and age? It belongs in a dumpster, sorry.

(I think the only "modern" arch that does this is PIC, and even only for program data - where you're not running anything "officially" C89 or later)

When I first learned C, it was K&R, pre-ANSI with old style function parameters. It is trivial to convert to ANSI C. The truth is C has barely changed in decades.

You should take a look at plan9port - a bunch of userspace tools from Plan 9, carefully ported to Linux with few changes. Maybe that's not PDP-whatever, but it is Sun-whatever. Either way, it's code that was written decades ago for a dead architecture.

Reply on news.ycombinator.com