Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

81–90 of 395 posts

Re: Modern C++ Won't Save Us

#81

Post by ajxs »

jmole wrote: post #15

Question - How does one write microcontroller code (or other memory-mapped I/O code) using a memory-safe language?

I feel this is quite a nuanced question, I can answer one aspect of it though. When I think of what 'memory-safety' means in this context I think mainly of buffer overflows, dangling pointers, etc, things that have nothing really to do with memory mapped IO. I can't speak for Rust, but I've recently been doing quite a bit of embedded development in Ada ( Disclaimer: Not an expert ) and it supports mapping variables onto a arbitrary memory addresses through a variety of means that don't forgo static typing and compile-time checking. You can use access-types which are the closest thing to C's pointers, they allow for direct memory access while still preventing a good deal of the issues arising from misuse of pointers. I'd say it's well worth checking out for yourself.

Re: Modern C++ Won't Save Us

#82

Post by AnimalMuppet »

kevin_thibedeau wrote: post #44
raphlinus wrote: post #10

From the article: > Dereferencing a nullptr gives a segfault (which is not a security issue, except in older kernels). I know a lot of people make that assumption, and compilers used to work that way pretty reliably, but I'm pretty confident it's not true. With undefined behavior, anything is possible.

Definitely not true. Consider an IoT device without an MMU.

Most of the ones of those I am familiar with had 0 as a non-writable address, so you'd still crash. [Edit: Though that's probably hardware specific, and the hardware was usually custom.] It might be called "bus error" or some such instead of "segfault", but it was pretty much the same behavior.

Re: Modern C++ Won't Save Us

#83

Post by raphlinus »

mjevans wrote: post #65
_wmd wrote: post #11

Earlier quoted context omitted.

Linux hit a related situation: a harmless null pointer dereference was treated by GCC as a signal that a subsequent isnull test could not be true, causing the test to be optimized away. https://lwn.net/Articles/575563/

My opinion on that, is that such code MUST NOT be optimized away. Instead it should be a compile error.

You might wish for that, but the ship has sailed. Undefined behavior means that the implementation can do whatever it can. That said, I do expect tools, both sanitizers and static analyzers to improve to detect more of these kinds of cases.

Re: Modern C++ Won't Save Us

#84

Post by leshow »

AnimalMuppet wrote: post #80
tatersolid wrote: post #41

Earlier quoted context omitted.

> think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. That’s the whole point: your caveat shows that’s it’s C/C++ which are unsafe in their very nature and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful. HPC are generally closed systems and have differ…

Well, it shows that there are aspects of C/C++ which are unsafe. But you don't have to use string_view or span, you know...

It was presented to show the "just use modern c++" counterargument to discussing the unsafety of c++ isn't a great argument. There are modern parts that are still unsafe.

Re: Modern C++ Won't Save Us

#85

Post by School-Cotton »

mjevans wrote: post #65
_wmd wrote: post #11

Earlier quoted context omitted.

Linux hit a related situation: a harmless null pointer dereference was treated by GCC as a signal that a subsequent isnull test could not be true, causing the test to be optimized away. https://lwn.net/Articles/575563/

My opinion on that, is that such code MUST NOT be optimized away. Instead it should be a compile error.

The problem, as far as I understand it (though I’m a layman), is that by the time the dead code optimization pass runs, the code has been transformed so much that there’s no obvious way for the compiler to tell the difference between “obvious programmer-intended null check that we shouldn’t optimize out” and “spurious dead code introduced by macro expansion” or (in C++) “by template instantiation”.

Re: Modern C++ Won't Save Us

#86

Post by [deleted] »

AnimalMuppet wrote: post #80
tatersolid wrote: post #41

Earlier quoted context omitted.

> think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. That’s the whole point: your caveat shows that’s it’s C/C++ which are unsafe in their very nature and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful. HPC are generally closed systems and have differ…

Well, it shows that there are aspects of C/C++ which are unsafe. But you don't have to use string_view or span, you know...

[deleted]

Re: Modern C++ Won't Save Us

#87

Post by School-Cotton »

raphlinus wrote: post #83
mjevans wrote: post #65

Earlier quoted context omitted.

My opinion on that, is that such code MUST NOT be optimized away. Instead it should be a compile error.

You might wish for that, but the ship has sailed. Undefined behavior means that the implementation can do whatever it can. That said, I do expect tools, both sanitizers and static analyzers to improve to detect more of these kinds of cases.

Well, not exactly. There are things that are UB according to the standard but that particular compilers give an option to make defined: see `-fwrapv`, for example.

Re: Modern C++ Won't Save Us

#88

Post by lpghatguy »

ajross wrote: post #64
arcticbull wrote: post #63

Earlier quoted context omitted.

It’s definitely easier to reason about than C++ because it errs on the side of safety and explicitness. You can use things you don’t understand without fear which straddles the boundary in a good way IMO. To your point that doesn’t make it simple. As a work-a-day hacker it’s completely become my go to language when I’m writing tools, libraries or just want to knock out a simple algorithm to prove myself right or wron…

> It’s definitely easier to reason about than C++ See... I don't think that's true, and argue the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary. I mean, sure, C++ has its crazy edge cases and its odd notions. But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code. Literally hundreds of tho…

Claiming that Rust is a language for 'The Elite' is amusing in light of the recent Rust website redesign, with the following headline[1]:

> Empowering everyone to build reliable and efficient software.

The language is entirely about inclusion, empowerment, and removing the fear of systems development.

[1]: https://www.rust-lang.org/

Re: Modern C++ Won't Save Us

#89

Post by leshow »

ajross wrote: post #64
arcticbull wrote: post #63

Earlier quoted context omitted.

It’s definitely easier to reason about than C++ because it errs on the side of safety and explicitness. You can use things you don’t understand without fear which straddles the boundary in a good way IMO. To your point that doesn’t make it simple. As a work-a-day hacker it’s completely become my go to language when I’m writing tools, libraries or just want to knock out a simple algorithm to prove myself right or wron…

> It’s definitely easier to reason about than C++ See... I don't think that's true, and argue the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary. I mean, sure, C++ has its crazy edge cases and its odd notions. But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code. Literally hundreds of tho…

> But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code.

Don't you kind of have to though? These invariants are in your code no matter what, in the case of Rust they are checked by the compiler (you don't necessarily have to understand every nuance, because it's checked for you), in C++ they aren't checked and are a potential bomb waiting to go off.

Re: Modern C++ Won't Save Us

#90

Post by arcticbull »

lpghatguy wrote: post #88
ajross wrote: post #64

Earlier quoted context omitted.

> It’s definitely easier to reason about than C++ See... I don't think that's true, and argue the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary. I mean, sure, C++ has its crazy edge cases and its odd notions. But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code. Literally hundreds of tho…

Claiming that Rust is a language for 'The Elite' is amusing in light of the recent Rust website redesign, with the following headline[1]: > Empowering everyone to build reliable and efficient software. The language is entirely about inclusion, empowerment, and removing the fear of systems development. [1]: https://www.rust-lang.org/

Perception always lags reality, and it definitely was hard to learn when I picked it up 3-4 years ago. Things have improved so much since then, with non-lexical lifetimes in R2018, better compiler errors, stdlib standardization, RLS + VSCode, etc.
Post reply on HN