4 ms·

What specific legacy cruft does bother you? I think it is a strength of C that it evolves it slowly and code from decades ago will still run. I also do not s

by uecker 1y ago

What specific legacy cruft does bother you? I think it is a strength of C that it evolves it slowly and code from decades ago will still run. I also do not see how having decades of legacy software is holding anybody back doing new stuff in C in a better way. New C code can be very nice.

pjmlp 1y ago
So slowly that what allowed for Morris worm is still present in C23, and now everyone is rushing into hardware memory tagging as a solution instead.
- uecker 1y ago
  Can you be more precise? Memory safety does not only affect C programs and - despite people repeating this over and over - I do not believe it is true that it is actually harder to build safe programs in C compared to many other languages. Ada and Rust have certainly some advantage, but I think also this is exaggerated.
  - pjmlp 1y ago
    Memory corruption caused by lack of bounds checking, or vocabulary types like the ones provided by SDS and glib. Microsoft had to come up with SAL during Windows XP SP2, Apple with -fbounds-safety alongside Safe C dialect for iBoot firmware, Oracle with ADI on Solaris/SPARC, Apple's ARM PAC extension, ARM and Microsoft's collaboration on Pluton and CHERI Morello, Apple, Microsoft, Google and Samsung's collaboration on ARM's MTE. Lots of money being spent on R&D, for something WG14 considers exaggerated.
    - uecker 1y ago
      Those extensions are mostly to be able to enhance safety of legacy code though and not necessary when writing new code that is safe. But it is only the later that is relevant when comparing to new alternative languages.
      - pjmlp 1y ago
        Where can we find examples of such newly written C code that is memory safe, given that language features that would make it possible are only now under discussion for future standards, after governments and industry pressure?
        uecker 1y ago
        Basically any code that does not use pointer arithmetic or raw pointer dereferences and instead puts string handling and buffer management behind abstractions. The new feature we will put in are not to enable safe programming, but to make it more convenient and to make safety demonstrable. And I wish there was actually some real industry interest to pushing this forward. Industry seems more interested into claiming this an unfixable problem and we all have to switch to Rust, which gives them another decade of punting the problems with existing code.
        pjmlp 1y ago
        So basically no examples, just hope people actually follow best practices, as usual. Why doesn't WG14 prove the industry wrong then?
        uecker 1y ago
        I could help with searching some public examples if you really do not know any code that uses safe string abstractions in C. But my original aim was to understand what specific "legacy cruft" in C is seen as problematic, and why its presence requires an entirely language to fix. So far, I did not get a good answer to this. I certainly do know some legacy cruft I want to see go but its presence does not prevent me from writing bounds-safe code. WG14 is a very small number of volunteers. It would help if the industry would actually invest development resources for safety on the compiler / language side and in cleaning up legacy code.
        pjmlp 1y ago
        Exactly, there are very few pearls of best practices in C, and those that exist, are probably in high integrity computing, with the relevant certification costs. When all major OS vendors, some of whom are also compiler vendors, see more return into investment, contributing their money to alternative language foundations, or open source projects, than sending their employees to either WG14, or WG21, it is kind of clear ISO isn't going the way they would like to. I would not call this an exaggeration, rather not listening. Additionally, it would not surprise me if one of Zig, Odin, Rust eventually started popping up on console DevKits, or Khronos standards as well.

by uecker 1y ago

pjmlp 1y ago

So slowly that what allowed for Morris worm is still present in C23, and now everyone is rushing into hardware memory tagging as a solution instead.

uecker 1y ago
Can you be more precise? Memory safety does not only affect C programs and - despite people repeating this over and over - I do not believe it is true that it is actually harder to build safe programs in C compared to many other languages. Ada and Rust have certainly some advantage, but I think also this is exaggerated.
- pjmlp 1y ago
  Memory corruption caused by lack of bounds checking, or vocabulary types like the ones provided by SDS and glib. Microsoft had to come up with SAL during Windows XP SP2, Apple with -fbounds-safety alongside Safe C dialect for iBoot firmware, Oracle with ADI on Solaris/SPARC, Apple's ARM PAC extension, ARM and Microsoft's collaboration on Pluton and CHERI Morello, Apple, Microsoft, Google and Samsung's collaboration on ARM's MTE. Lots of money being spent on R&D, for something WG14 considers exaggerated.
  - uecker 1y ago
    Those extensions are mostly to be able to enhance safety of legacy code though and not necessary when writing new code that is safe. But it is only the later that is relevant when comparing to new alternative languages.
    - pjmlp 1y ago
      Where can we find examples of such newly written C code that is memory safe, given that language features that would make it possible are only now under discussion for future standards, after governments and industry pressure?
      - uecker 1y ago
        Basically any code that does not use pointer arithmetic or raw pointer dereferences and instead puts string handling and buffer management behind abstractions. The new feature we will put in are not to enable safe programming, but to make it more convenient and to make safety demonstrable. And I wish there was actually some real industry interest to pushing this forward. Industry seems more interested into claiming this an unfixable problem and we all have to switch to Rust, which gives them another decade of punting the problems with existing code.
        pjmlp 1y ago
        So basically no examples, just hope people actually follow best practices, as usual. Why doesn't WG14 prove the industry wrong then?
        uecker 1y ago
        I could help with searching some public examples if you really do not know any code that uses safe string abstractions in C. But my original aim was to understand what specific "legacy cruft" in C is seen as problematic, and why its presence requires an entirely language to fix. So far, I did not get a good answer to this. I certainly do know some legacy cruft I want to see go but its presence does not prevent me from writing bounds-safe code. WG14 is a very small number of volunteers. It would help if the industry would actually invest development resources for safety on the compiler / language side and in cleaning up legacy code.
        pjmlp 1y ago
        Exactly, there are very few pearls of best practices in C, and those that exist, are probably in high integrity computing, with the relevant certification costs. When all major OS vendors, some of whom are also compiler vendors, see more return into investment, contributing their money to alternative language foundations, or open source projects, than sending their employees to either WG14, or WG21, it is kind of clear ISO isn't going the way they would like to. I would not call this an exaggeration, rather not listening. Additionally, it would not surprise me if one of Zig, Odin, Rust eventually started popping up on console DevKits, or Khronos standards as well.