3 ms·

I maintain that C is fine and optimising compilers converting 'bad' C into dangerously broken binaries is not fine. We don't need to replace C to make it safe,

I maintain that C is fine and optimising compilers converting 'bad' C into dangerously broken binaries is not fine. We don't need to replace C to make it safe, we need to take the edge off undefined behaviour justified compiler rewrites.

rightbyte 4y ago
I believe the main culprit is that the compiler guys want to optimize away Cpp templates, where programmer intent is not as explicit as in C.
- pjmlp 4y ago
  C has enough UB of its own, no need to bring C++ into the picture.
  - rightbyte 4y ago
    I meant that the shared compiler code with Cpp is the problem. At least in gcc. I don't know about Clang.
- JonChesterfield 4y ago
  I attribute it to benchmarks. Spec and the like. Where you can indeed make the benchmarks faster by leaning into UB. No signed overflow? Branch gone from that loop. Prove these two things can't alias because the pointer provenance model says they don't and you can rearrange the loads and stores. The collateral damage from that line of work is high though.
  - rightbyte 4y ago
    Ye you might be correct. I think they are overreaching a bit in the eagerness to optimize.
Kototama 4y ago
Saying C is fine, does not make it fine though. The facts speak for themselves: even the best programmers in this world which are extremely conscious about security have vulnerabilities in the software they wrote because of C. There were two remotes vulnerabilities in OpenBSD since it's creation, more recently there was a vulnerability in the ping utility of FreeBSD, etc. C without undefined behaviors is not C anymore by the way. It would be something else.
- JonChesterfield 4y ago
  Strictly C where your implementation has provided sane definitions of undefined behaviour is still C. The implementation is free to provide definitions of undefined behaviour, and no diagnostic required doesn't mean no diagnostic permitted. Offhand I think all the undetectable parts are a quirk of separate compilation which is solvable by linking an IR instead of machine code. That would probably be a high value project to implement.

rightbyte 4y ago

I believe the main culprit is that the compiler guys want to optimize away Cpp templates, where programmer intent is not as explicit as in C.

pjmlp 4y ago
C has enough UB of its own, no need to bring C++ into the picture.
- rightbyte 4y ago
  I meant that the shared compiler code with Cpp is the problem. At least in gcc. I don't know about Clang.
JonChesterfield 4y ago
I attribute it to benchmarks. Spec and the like. Where you can indeed make the benchmarks faster by leaning into UB. No signed overflow? Branch gone from that loop. Prove these two things can't alias because the pointer provenance model says they don't and you can rearrange the loads and stores. The collateral damage from that line of work is high though.
- rightbyte 4y ago
  Ye you might be correct. I think they are overreaching a bit in the eagerness to optimize.

Kototama 4y ago

Saying C is fine, does not make it fine though. The facts speak for themselves: even the best programmers in this world which are extremely conscious about security have vulnerabilities in the software they wrote because of C. There were two remotes vulnerabilities in OpenBSD since it's creation, more recently there was a vulnerability in the ping utility of FreeBSD, etc. C without undefined behaviors is not C anymore by the way. It would be something else.

JonChesterfield 4y ago
Strictly C where your implementation has provided sane definitions of undefined behaviour is still C. The implementation is free to provide definitions of undefined behaviour, and no diagnostic required doesn't mean no diagnostic permitted. Offhand I think all the undetectable parts are a quirk of separate compilation which is solvable by linking an IR instead of machine code. That would probably be a high value project to implement.