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

Let’s sunset C/C++

trevorjim.com

Post reply on HN
Print view View original

121–130 of 137 posts

Re: Let’s sunset C/C++

#121

Post by steveklabnik »

pmelendez wrote: post #117
steveklabnik wrote: post #113

Earlier quoted context omitted.

Arc vs Rc compared to shared_ptr was what I was going to say for overhead, as well as things like the lack of move constructors, which (should) make Vec faster than std::vec. For stronger guarantees, I was going to point out that if you std::move a uniq_ptr, it becomes null, but Rust prevents using a Box that's been moved at compile time. Your example is good here too.

> the lack of move constructors, which (should) make Vec faster than std::vec. So you are saying that the lack of move constructors (hence copying the structure) will make Vec faster than std::vector? I don't follow that logic, wouldn't it actually be slower? > I was going to point out that if you std::move a uniq_ptr, it becomes null The original becames null because the semantic is actually tranfering ownership whi…

   > I don't follow that logic,
Specifically, I mean that when the vector changes size, the vector needs to reallocate. In Rust, since there are no move constructors, it's just a memcpy of the whole chunk of memory, one big one. Very straightforward and fast. In C++, you need to call all those move constructors.

  > The original becames null because the semantic is actually tranfering ownership
Absolutely. In Rust, this is tracked at compile time, and attempting to use after the move is a compile-time error. In C++, you'll get a null pointer dereference. (I _think_ that technically it's in an 'unspecified' state, not a null one, but on my system, null is what I get).

Re: Let’s sunset C/C++

#122

Post by steveklabnik »

pmelendez wrote: post #118
bbatha wrote: post #111

Earlier quoted context omitted.

shared_ptr uses an atomic counter. In rust you can choose to use an atomic ref count or not. The type system is sufficiently smart to ensure that you do not use the non-atomic one in a thread unsafe context. C++ has no ability to do so, so it does not provide a thread unsafe version. Additionally, in C++ there's nothing stopping me from wrapping a unique_ptr around a pointer that's aliased else where. This violates t…

>C++ has no ability to do so, so it does not provide a thread unsafe version. In which case would you like to enforce a thread unsafe version? >Additionally, in C++ there's nothing stopping me from wrapping a unique_ptr around a pointer that's aliased else where. This violates the guarantees of a unique_ptr and forces the user to make sure its invariants are held. In Rust the compiler ensures that your Box (Rust's un…

  > In which case would you like to enforce a thread unsafe version?
Any time you don't use shared_ptr in a multithreaded context, you're paying extra for the overhead of atomics. In Rust, if you need shared ownership, but you're not doing anything with threads, you can remove that overhead. If you then later try to use it across threads, the compiler won't let you, until you switch to using Arc.

Re: Let’s sunset C/C++

#123

Post by pmelendez »

steveklabnik wrote: post #121
pmelendez wrote: post #117

Earlier quoted context omitted.

> the lack of move constructors, which (should) make Vec faster than std::vec. So you are saying that the lack of move constructors (hence copying the structure) will make Vec faster than std::vector? I don't follow that logic, wouldn't it actually be slower? > I was going to point out that if you std::move a uniq_ptr, it becomes null The original becames null because the semantic is actually tranfering ownership whi…

> I don't follow that logic, Specifically, I mean that when the vector changes size, the vector needs to reallocate. In Rust, since there are no move constructors, it's just a memcpy of the whole chunk of memory, one big one. Very straightforward and fast. In C++, you need to call all those move constructors. > The original becames null because the semantic is actually tranfering ownership Absolutely. In Rust, this i…

> mean that when the vector changes size, the vector needs to reallocate You can control how often the vector changes the size and a lot of times you can even prevent that.

> In Rust, since there are no move constructors, it's just a memcpy.

memcpy is actually slower that move the ownership of a buffer, that's why you avoid copying as much as you can (std::vector also uses memcpy inside).

> In Rust, this is tracked at compile time, and attempting to use after the move is a compile-time error.

It is nice to get a misuse at compile time, but my point is that once you transfer the ownership of the pointer you shouldn't be using that unique_ptr anymore. I'm probably biased but I don't see this "accidental" misuse happening often (tbh I haven't seen it ever and I have seen some horrible things in C++ before)

Re: Let’s sunset C/C++

#124

Post by pmelendez »

steveklabnik wrote: post #122
pmelendez wrote: post #118

Earlier quoted context omitted.

>C++ has no ability to do so, so it does not provide a thread unsafe version. In which case would you like to enforce a thread unsafe version? >Additionally, in C++ there's nothing stopping me from wrapping a unique_ptr around a pointer that's aliased else where. This violates the guarantees of a unique_ptr and forces the user to make sure its invariants are held. In Rust the compiler ensures that your Box (Rust's un…

> In which case would you like to enforce a thread unsafe version? Any time you don't use shared_ptr in a multithreaded context, you're paying extra for the overhead of atomics. In Rust, if you need shared ownership, but you're not doing anything with threads, you can remove that overhead. If you then later try to use it across threads, the compiler won't let you, until you switch to using Arc.

> In Rust, if you need shared ownership, but you're not doing anything with threads, you can remove that overhead.

If I am following you well, then what you are saying is that you if you are in a single thread application you don't need to use a shared_ptr equivalent. Wouldn't that mean that you are using a garbage collected pointer? (Which should have a greater overhead than a shared pointer) because otherwise you would be using plain old raw pointers (with all its problems).

Re: Let’s sunset C/C++

#125

Post by steveklabnik »

pmelendez wrote: post #124
steveklabnik wrote: post #122

Earlier quoted context omitted.

> In which case would you like to enforce a thread unsafe version? Any time you don't use shared_ptr in a multithreaded context, you're paying extra for the overhead of atomics. In Rust, if you need shared ownership, but you're not doing anything with threads, you can remove that overhead. If you then later try to use it across threads, the compiler won't let you, until you switch to using Arc.

> In Rust, if you need shared ownership, but you're not doing anything with threads, you can remove that overhead. If I am following you well, then what you are saying is that you if you are in a single thread application you don't need to use a shared_ptr equivalent. Wouldn't that mean that you are using a garbage collected pointer? (Which should have a greater overhead than a shared pointer) because otherwise you w…

  > you don't need to use a shared_ptr equivalent
Well, it's the same thing, but without the atmoics. Rc and Arc only differ in the instructions used to update the count, Rc uses regular increment, Arc uses atomic increment. The code is otherwise the same.

Re: Let’s sunset C/C++

#126

Post by steveklabnik »

pmelendez wrote: post #123
steveklabnik wrote: post #121

Earlier quoted context omitted.

> I don't follow that logic, Specifically, I mean that when the vector changes size, the vector needs to reallocate. In Rust, since there are no move constructors, it's just a memcpy of the whole chunk of memory, one big one. Very straightforward and fast. In C++, you need to call all those move constructors. > The original becames null because the semantic is actually tranfering ownership Absolutely. In Rust, this i…

> mean that when the vector changes size, the vector needs to reallocate You can control how often the vector changes the size and a lot of times you can even prevent that. > In Rust, since there are no move constructors, it's just a memcpy. memcpy is actually slower that move the ownership of a buffer, that's why you avoid copying as much as you can (std::vector also uses memcpy inside). > In Rust, this is tracked a…

  > (std::vector also uses memcpy inside).
I don't think I am communicating myself clearly, so I'll just bow out about this issue, until I have an example ready. I should write one anyway, I just don't have it at the moment.

  > I'm probably biased but I don't see
this "accidental" misuse happening > often

While that may be true, as the article points out, all it takes is for someone, anywhere, to slip up once, and then you possibly have a serious security violation. Having the compiler double-check your work is nice.

Re: Let’s sunset C/C++

#127

Post by p0nce »

pjmlp wrote: post #86
p0nce wrote: post #40

C++ is safe enough, provided you use the tools like Intel Inspector, valgrind, and static analyzers. With C++11 memory corruptions became a somewhat rare occurence.

Which most developers actually don't use, specially the 9-5 developers.

Indeed. C++ is incredibly fragmented, I guess that could cause its demise before safety becomes an actual concern for language choices.

Re: Let’s sunset C/C++

#128

Post by AnimalMuppet »

The article claims that the problem with Flash is not so much Flash itself, but that it's written in C/C++. It "proves" the point by listing a bunch of high-profile exploits in various other systems, then repeats the claim that C/C++ is the problem, and advocates abandoning C/C++.

That's... not exactly proof. It's barely even evidence.

Yes, you can argue "all these programs have all these flaws, and all are written in C/C++". And that's true. They are written in C/C++, and they have these flaws.

Now let's look at the programs that do the same kinds of things, and are as widely used, and are not written in C/C++, and compare the number of exploits... oh, you don't have a handy list of equivalent programs to compare? Go work on that; I'll wait.

The fundamental problem is that these programs are trying to safely handle hostile input, with attackers having essentially infinite time to experiment and craft attacks, including attacks that the authors didn't know that they needed to defend against at the time the code and/or the spec were written.

Would the whole world be safer if everything were at least written in Java? Yes, it might be safer, but not safe. And it would take more resources, and often take longer to start up. And it would be vulnerable to bugs in the design and implementation of the JVM, which would become a single point of failure for a lot of software. That world would, perhaps, be somewhat safer, but it wouldn't be the security paradise that the article envisions.

Not everyone is a fool who doesn't use the tools you think are best...

Re: Let’s sunset C/C++

#129

Post by iofj »

sklogic wrote: post #87
monochr wrote: post #58

Earlier quoted context omitted.

>But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. You can't write safe code in any Turing complete language. That's the whole point of Turing completeness. The only reason why memory attacks are as common as they are is because C like languages are the most popular ones. If we replaced everything written with C to a "safe" language like, I don't know Haskell?, we'd h…

> You can't write safe code in any Turing complete language. Correct. But, a lot of code is written in Turing complete languages which does not really require any Turing completeness at all. And some code should be implemented in non-Turing-complete, verifiable languages.

Of course you can. You can, for instance, include an automatically verified proof that your code terminates for finite inputs.

This is in fact where the newest academic languages are going. In dependantly typed languages bounds checks are only done in theory. you have to include a proof that your indexes are within bounds, and the compiler verifies that proof. If it checks out, it compiles. If not, back you go. Far safer than java/go and the like and far faster than c++. These languages tend to allow pointer arithmetic too, for beating it in speed is almost impossible.

Re: Let’s sunset C/C++

#130

Post by pjmlp »

andresmanz wrote: post #88
gizmo wrote: post #49

Earlier quoted context omitted.

No need to panic, nobody is coming to take your precious pointer arithmetic away. If you want to write unsafe code, go ahead. But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. We're talking about classes of security bugs that just don't exist in managed languages. Bugs that can't happen in languages like Rust either because it forces programmers to indicate ownership…

> But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. Then you've picked the wrong profession. You write that like it was a fact, while it's obviously nothing more than a lack of skill (and maybe knowledge) on your side. If I chose a language primarily because it's 'safe', that would mean that either I'm pretty bad at writing safe code, or that I'm just unnecessarily la…

Assuming you work alone maybe yes. However most of us work in teams.

C and C++ have long proven that with average skills teams, the end result is lurking buffer exploits, dangling pointers, corrupted memory somewhere in the code base, that usually take days to sort out.

Post reply on HN