Comment by ho_schi | Hacker News Reader

Comment by ho_schi | Hacker News Reader

Regarding the addition to libxx: I’m not fond of adding an increasing number of specific compiler options which need to be turned on for memory-safety. It should be default whenever possible. What do you think?

I love -faddress=sanitizer or -fsanitize. The historically growing number of warnings which should be turned on are an issue. For example the options -Wconversion, -Wsign-conversion and -Warith-conversion shall be default with C++XX. And if your code doesn’t compile, fix it, use and older revision or turn it deliberately off (saying: I’m aware, read the handbook, I take the risk). Doing such changes with language revisions allows people to take notice about it without surprise.

I want some ideas of CPP2/cppfront[1] in C++XX. Finally using #unsafe when needed, like Rust. C++ does evolve over decades, more like other languages.

[1] https://github.com/hsutter/cppfront

BTW. Use the AddressSanitizer. Please! The toolchain improved the usage and safety of the language so much. It wasn’t available twenty years ago but it is now.

I think what you're looking for are profiles.

- https://github.com/BjarneStroustrup/profiles

Ie. rather than a bunch of tools helping you find undefined behaviour (or left-and-right improvements of what the behaviour should be) you'd like to be able to make high level claims about your code and have the compiler validate those guarantees.

C++ having a huge C++ legacy, things of course are never easy. So for the time being this is just work-in-progress.

First of all they have to be designed and voted in.

If WG21 is actually open to having them, ISO C++29 is probably when they might land, then given the compiler velocity with previous standards, expect at least 5 years to mature, on the top three, let alone everyone else.

If I am not dead by then, I will certainly be retired.

How long will the industry be willing to wait for profiles?

> BTW. Use the AddressSanitizer. Please! The toolchain improved the usage and safety of the language so much.

In general I agree with the sentiment, use AddressSanitizer in testing/debugging. However it's not meant to be a hardening option, AFAIK, so I advise against using it in production (along with other sanitizers), even if you can live with the performance hit.

Yep.

Theoretically it is possible but libasan is not intended for linking or shipping in production. Also stuff like LeakSanitizer[1] actually cannot [1] be used with GDB.

While shipping debug symbols is something I recommend and has no side-effects aside from mere file-size (debug symbols are only loaded when used).

Usual exceptions apply as you encounter them.

[1] https://github.com/google/sanitizers/issues/857

I think the compilers would be allowed to just make your default warning changes as non-fatal diagnostics aren't a conformance matter. So you probably need to lobby GCC, Clang and MSVC.

Herb's discussion of "unsafe" for Cpp2 is... misleading. Rust's unsafe does not turn off checking. If you take some safe Rust which compiles (even if it panics) and you just wrap that in a block with the unsafe keyword, all you get for your trouble is a new diagnostic (by default a warning) saying not to do that because it's futile to use an unsafe block here. No checks are switched off, no "performance" shortcuts are added, if it would panic before it still does now - it's just the same code with a frivolous "unsafe" sign on it.

Swift does this, but their release cycle is currently more frequent and the roadmap is (possibly) more clear. Paraphrasing:

    Warning: <Certain undesirable behavior>
    will be an error in Swift <Version
    + 1>.

I’m not sure if it’s an huge improvement, but it’s easy to block all forward warnings with `-Werror` to clean up right away.

both c++ and Rust emit these kind of warnings to deprecate previously allowed constructs that are deemed undesirable, but I don’t follow how it relates to this particular topic

Reply on news.ycombinator.com