For systems programming languages, safe by default with scoped unsafe code is a Pareto improvement on unsafe everywhere.
Modern C++ Won't Save Us
31–40 of 395 posts
Re: Modern C++ Won't Save Us
#32From 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.
The irony is it's mostly unsafe if you test for the null, such that the compiler can omit a test, but if there's no evidence the pointer can be null you just get a normal memory access. The optimizer is not optimized for most intuitive behavior.
The null checks are only optimized away if you've already derefenced the pointer before the null check within a scope. Optimizer rationale being youve already derefenced it, so it must not be null, therefore the null check is unnecessary.
Also, you can "safely" dereference nullptr, just so long as you dont attempt to actually access the memory. C++ references are nothing more than a fancy pointer with syntactic sugar.
For example: int* foo = nullptr; int& bar = *foo; // no blow up std::cout My personal $0.02 is that the C++ standard falls short with language like "undefined/unspecified behavior, no diagnostic required." A lot of problems could be prevented if diagnostics (read: warnings) were required, assuming devs pay attention to the warnings, which doesnt always happen. For example: Google ProtoBuf has chosen to ignore at their own and clients' peril potential over/underflow errors and vulnerabilities by ignoring signed/unsigned comparison warnings.
Re: Modern C++ Won't Save Us
#33I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…
C++ does have its positives, as you mentioned, but those positives do not make its negatives go away, nor having negatives means that there aren't positives. You can dislike some parts of the language while still using it for its positive aspect - that doesn't mean the negative parts do not exist nor mentioning them means that there are no positives.
Re: Modern C++ Won't Save Us
#34I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…
Yeah, agreed. The points in the article are valid , but quirks you learn and get past the first time. I still shoot myself in the foot sometimes even though I don't have a single bare new/malloc without a shared/unique ptr! But that's C++ for you. But, C/C++ is the best option for us for high-performance network processing. We're dabbling with Rust for small applications where we would use Python previously and it's…
> The points in the article are valid, but quirks you learn and get past the first time. I still shoot myself in the foot sometimes even though I don't have a single bare new/malloc without a shared/unique ptr! But that's C++ for you.
I think the article maybe doesn't do enough to outline the full extent of the problem by focussing on a few counterintuitive cases that are present in C++17, because you're right, all of those cases in the article are ones that can be learned and remembered without issue. The real problem, as I see it, is actually that the core language semantics mean that there's no foreseeable end to the foot-shooting treadmill. Since the language is fundamentally permissive of such things, it's likely that further spec revisions will introduce abstractions like string_view that are easy to use unsafely, aren't flagged by static analysis tools, and end up in security-critical code.
Because this feels like a necessary disclaimer, I don't think that fact justifies migrating every active C++ codebase out there to Rust or anything, since pragmatically speaking there are a lot more factors beyond just core language semantics that go into evaluating the best choice of implementation language. I guess my takeaway is neatly expressed by the post title: there's a sense that I get from C++ users (granted, maybe only naive ones) that sticking to the features and abstractions introduced in C++11/14/17/etc basically eliminates all of the potholes of old, and it's evident that that's not true and will probably continue to be not true.
Re: Modern C++ Won't Save Us
#35Re: Modern C++ Won't Save Us
#36Can someone at least make a linter that ensures you only use a "safe" subset of C++?
Re: Modern C++ Won't Save Us
#37"Don't be clever". Yes. In the CppCon 2017 opening keynote: The Learning and Teaching Modern C++. The accompagnying slide says "Don't be (too) clever" but I can't promounce parentheses :-). My point was to discourage overly clever code because "clever code" is hard to write, easy to get wrong, harder to maintain, and often no faster than simpler alternatives because it can be hard to optimize. - Bjarne Stroustrup
Re: Modern C++ Won't Save Us
#38Question - How does one write microcontroller code (or other memory-mapped I/O code) using a memory-safe language?
Use MicroPython (http://micropython.org/)
Re: Modern C++ Won't Save Us
#39Earlier quoted context omitted.
By calling unsafe code. :) The semantics and guarantees offered by the interface vary, but that's the short version.
I have over 10 years of professional C++ and helped teach a course on it in college. One of my observations, and I may be off, is that a fair number of C++ users tend to take on a kind of macho attitude about it: it's a hammer for every nail, if you make certain mistakes you shouldn't use it or maybe be programming at all, garbage collection and other safety apparatus are kind of like training wheels while the "big b…
I've over 15 years professional experience in C++, around 16 years in C#, and around 14 in Python, all overlapping. For me, it's about using the right tool for the job.
It's not being a macho developer, but sometimes you need the hammer that C++ is, and you'll probably hit your thumb a few times using it.
Re: Modern C++ Won't Save Us
#40Earlier quoted context omitted.
The irony is it's mostly unsafe if you test for the null, such that the compiler can omit a test, but if there's no evidence the pointer can be null you just get a normal memory access. The optimizer is not optimized for most intuitive behavior.
The null checks are only optimized away if you've already derefenced the pointer before the null check within a scope. Optimizer rationale being youve already derefenced it, so it must not be null, therefore the null check is unnecessary. Also, you can "safely" dereference nullptr, just so long as you dont attempt to actually access the memory. C++ references are nothing more than a fancy pointer with syntactic sugar…
Dereferencing a null pointer to convert it to a reference causes undefined behavior, there's nothing safe about it!
"Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior."