Why Safety Profiles Failed • Hacker News Board

Re: Why Safety Profiles Failed

#231

Post by spookie » Tue, Oct 29, 2024, 5:20 PM UTC

pjmlp wrote: post #216

spookie wrote: post #182

Earlier quoted context omitted.

Honestly, I blame MSVC for a lot of lost momentum when adopting new standards, given it takes them more than 4 years implementing those features. Ofc, this isn't the case for C++11 today, but a lot of projects were started prior to 2015. And don't get me started on C itself. Jesus Christ.

They certainly aren't to blame for the state of C and C++ adoption on UNIX, Sony and Nintendo, and embedded. They are the only C++ compiler that properly supports all C++20 modules use cases, while clang still doesn't do Parallel STL from C++17, for example. They support C17 nowadays, where many embedded folks are slowly adopting C99. And the UNIX story outside clang and GCC is quite lame, most still stuck in C++14,…

I wouldn't say they "support" C17. Perhaps with a big asterisk. Even with C11, they implemented _parts_ of the standard, but didn't ship some of its libs (threads come to mind). Same deal in C17. Any hopes of porting over standard compliant C code to MSVC are met with lots of additional porting work.

Also, if we do move the discussion outside GCC and Clang, then I don't know what to say man. Why not use GCC or Clang? Are there many UNIX out there not having either? Seems unlikely.

Re: Why Safety Profiles Failed

#232

Post by aw1621107 » Tue, Oct 29, 2024, 10:05 PM UTC

mimd wrote: post #223

aw1621107 wrote: post #213

Earlier quoted context omitted.

> If it requires the programmer to bear the responsibility for proper usage (eg. must use checked_add not rely on panic), how's that different than the issues with undefined behavior? It comes down to the blast radius for a mistake. A mistake involving UB can potentially result in completely arbitrary behavior. A mistake in the safe subset of a language is still a mistake, but the universe of possible consequences is…

Thanks for the input and links. I'll need to test out the costs of the mitigations. BTW, I found one of the rust rfc documents helpful for understanding the borrow checker. Do you know if there is a similar rust RFC document for the upcoming polonius borrowchecker, even if it's just a working copy? I'm having trouble finding anything beyond some blog posts.

Unfortunately I'm not super-familiar with developments around Polonius, so chances are what I can point you towards are the same things you found when searching. The most relevant bits appear to be the Polonius book [0] linked from the repo [1], but I don't know how up to date the book is or if there are more up-to-date resources. The RFC book [2] doesn't seem to have anything obviously about Polonius either.

[0]: https://rust-lang.github.io/polonius/

[1]: https://github.com/rust-lang/polonius

[2]: https://rust-lang.github.io/rfcs/

Re: Why Safety Profiles Failed

#233

Post by aw1621107 » Tue, Oct 29, 2024, 10:08 PM UTC

tialaramex wrote: post #222

aw1621107 wrote: post #221

Earlier quoted context omitted.

> You definitely can't have all of "Non-type template parameters" (the C++ equivalent of const generics) in Rust because some of it is unsound. Just to clarify, does this mean NTTP in C++ is unsound as-is, or that trying to port C++ NTTP as-is to Rust would result in something unsound?

It is possible to write unsound code using NTTP in C++ unsurprisingly. In C++ that's just your fault as the programmer, don't make mistakes. So the compiler needn't check. I think NTTP abuse that's actually unsound is rare in production, but the problem is that's my insight as a human looking at the code, I'm not a compiler. The Rust equivalent would need to be checked by the compiler and I think this only really del…

> It is possible to write unsound code using NTTP in C++ unsurprisingly.

Do you mind pointing me to some resources where I can learn more and/or give some keywords I can use to try to look around? This is admittedly the first time I've heard of C++ NTTP being unsound.

> As a whole concept you could probably say that the C++ NTTP is "unsound as-is" but that's so all-encompassing as to not be very useful, like saying C++ integer arithmetic is unsound.

That's fair, and that imprecision was entirely on me. I was primarily interested in the "source" of the unsoundness - whether it was inherent to however C++ does it, or whether C++'s NTTP is sound but a naive port of it to Rust would be unsound due to how generics differ from templates.