4 ms·

Trust the programmer is kind of still with us. Compilers assume the programmer is somehow capable of keeping perfect track of all the many footguns and somehow

Trust the programmer is kind of still with us. Compilers assume the programmer is somehow capable of keeping perfect track of all the many footguns and somehow doesn't trip over them. I don't think that's what it used to mean. > there should be no invention, without exception _Generic? The _Atomic mess? I've been vaguely thinking I need an off ramp from C as it staggers towards a more dangerous and annoying C++ dialect. Currently I think the right play is to write a C99 compiler that doesn't use UB => ruin as an optimising trick that incidentally stomps all over what the programmer thought would happen.

steveklabnik 3y ago
> Trust the programmer is kind of still with us. Yes, the post isn't saying that it's gone, it is saying that it should be gone, in the future. > _Generic? The _Atomic mess? I do not know the story behind these features, and so your point is a bit confusing to me. That said, I think what you're saying is that these are both inventions, and therefore, this principle isn't true. From the post: > For starters, we’ve shown we’re perfectly comfortable with invention during the C11 and C23 cycles. If you have any pointers to the story about standardizing these features, I'd love to hear about them though. > Currently I think the right play is to write a C99 compiler that doesn't use UB => ruin as an optimising trick that incidentally stomps all over what the programmer thought would happen. I do think that this is a thing that a lot of people want, but I am unsure that it is a thing that is possible, without seriously inhibiting optimizations. And if you're okay with that, you can compile at -O0. But maybe there is some universe in which you could write different optimizations. Only one way to find out! If you did pull that off, I'm sure your compiler would be popular.
- JonChesterfield 3y ago
  Generic and atomic are inventions where the prior art was much better. Function overloading via name mangling is simpler, faster and composes better than generic. Atomic as an operation (the gcc intrinsics) works better than as a type qualifier, especially given the type aliasing -> UB idea. Mostly because atomic is a property of something like "load" or "add", not of a register or an address. I'm pretty sure whole program optimisation can do the majority of the performance work of the aliasing assumptions. Things like signed integers never overflow are more difficult. My pet theory is that a C compiler that emits machine code that follows a thin layer over the target assembly for semantics will be fast enough for most things C gets used for.
  - steveklabnik 3y ago
    Ah thanks. I have never used _Generic, but I fully agree that "atomics as an operation rather than a type qualifier" is the superior design.
matheusmoreira 3y ago
We just need C99 with compiler flags that define the undefined behavior. Basically just turn off strict aliasing and force the compiler to assume 2's complement as the signed integer representation. The -fno-strict-aliasing and -fwrapv flags fix a lot of problems. There's been some pretty good quality of life features introduced by recent standards. Just backport them to C99 or something.

steveklabnik 3y ago

> Trust the programmer is kind of still with us. Yes, the post isn't saying that it's gone, it is saying that it should be gone, in the future. > _Generic? The _Atomic mess? I do not know the story behind these features, and so your point is a bit confusing to me. That said, I think what you're saying is that these are both inventions, and therefore, this principle isn't true. From the post: > For starters, we’ve shown we’re perfectly comfortable with invention during the C11 and C23 cycles. If you have any pointers to the story about standardizing these features, I'd love to hear about them though. > Currently I think the right play is to write a C99 compiler that doesn't use UB => ruin as an optimising trick that incidentally stomps all over what the programmer thought would happen. I do think that this is a thing that a lot of people want, but I am unsure that it is a thing that is possible, without seriously inhibiting optimizations. And if you're okay with that, you can compile at -O0. But maybe there is some universe in which you could write different optimizations. Only one way to find out! If you did pull that off, I'm sure your compiler would be popular.

JonChesterfield 3y ago
Generic and atomic are inventions where the prior art was much better. Function overloading via name mangling is simpler, faster and composes better than generic. Atomic as an operation (the gcc intrinsics) works better than as a type qualifier, especially given the type aliasing -> UB idea. Mostly because atomic is a property of something like "load" or "add", not of a register or an address. I'm pretty sure whole program optimisation can do the majority of the performance work of the aliasing assumptions. Things like signed integers never overflow are more difficult. My pet theory is that a C compiler that emits machine code that follows a thin layer over the target assembly for semantics will be fast enough for most things C gets used for.
- steveklabnik 3y ago
  Ah thanks. I have never used _Generic, but I fully agree that "atomics as an operation rather than a type qualifier" is the superior design.

matheusmoreira 3y ago

We just need C99 with compiler flags that define the undefined behavior. Basically just turn off strict aliasing and force the compiler to assume 2's complement as the signed integer representation. The -fno-strict-aliasing and -fwrapv flags fix a lot of problems. There's been some pretty good quality of life features introduced by recent standards. Just backport them to C99 or something.