undefined | Better HN

0 pointsprerok5d ago0 comments

Somewhat true, but C is pretty close to translating directly to machine code, even if most compilers now do so many complex things the assembly can be pretty far off. My point being is that if you have a type int in your program, it's specifically tied to the byte size of an integer on the target platform. While it can be 8, 16, 32, 64 bits, it's defined based on what the target platform supports efficiently.

So, when you say, "it's purely the language", I have to disagree. The language means different things on different platforms but it's still defined exactly on the target platform. And it's efficient on that platform.

Nowadays, we prefer correct vs. efficient, which I do agree with, of course. But, I also understand why C is like it is. It is possible to claim it's a problem of the language but I would argue that it is not. C gives us barebones and working with it we have to know this. If that's not needed then sure, other languages will be easier to work with.

0 comments

thomashabets25d ago

> C is pretty close to translating directly to machine code

The C standard defines only its abstract machine, not actual hardware.

> The language means different things on different platforms but it's still defined exactly on the target platform

It's implemented to support a target platform, so that programs behave as if they ran on the abstract machine.

It'd be nice if we could move more stuff from UB to implementation defined.

Do keep in mind that target platform can change, in this regard. E.g. IIRC OpenBSD doesn't guarantee the ABI backward compatibility that Linux does, and can change things like size of int if they want, between versions.

> I also understand why C is like it is

Yup. It can be true that I understand why, and still understand that it's 2026.

j / k navigate · click thread line to collapse