undefined | Better HN

0 pointsTracist7y ago0 comments

> It has been many years since I shipped a memory bug in C++. It is just not a real worry for me.

The whole comment sounds so much like well written satire, but I think he's being serious.

0 comments

I agree with him. in many practical applications with well design class hierarchies it just really isn't much of an issue. Hasn't been for me either.

fetbaffe7y ago

> with well design class hierarchies

:eyes:

vasilipupkin7y ago

you can roll eyes at me all you want, but I've been programming in C++ for a long time. These memory access issues just don't seem to be a big problem for us in practice. That's because we wrap all raw memory manipulation in appropriate classes for our application, so it's just not an issue. I agree it could be an issue in theory.

ncmncm7y ago

He rolls his eyes at "hierarchies". Libraries do make the difference.

Somebody else interjected Design Patterns. You can define a design pattern as a weakness in your language's ability to express a library function to do the job.

aldanor7y ago

... and with proper use of Design Patterns!

paulmooreparks7y ago

Why is it difficult to believe? I've also written plenty of C++ code without memory bugs. It's not that hard if you play by a few simple rules.

dodobirdlord7y ago

> I've also written plenty of C++ code without memory bugs.

The classic response to this is "That you know of." Consider that even quality-conscious projects with careful code review like Chrome have issues like this use-after-free bug from time to time.

https://googleprojectzero.blogspot.com/2019/04/virtually-unl...

So when people claim that they personally don't write memory bugs I tend to assume that they are mistaken, and that the real truth is that they haven't yet noticed any of the memory bugs that they have written because they are too subtle or too rare to have noticed.

tpolzer7y ago

Chrome is in an exceptionally hard place because of its JIT. Your language cannot tell you if it's safe for your JIT to omit a bounds check.

comex7y ago

That post describes two vulnerabilities: one is in the JIT, but the other one is in regular old C++ code. More generally, JIT bugs are a relatively small minority of browser vulnerabilities. More often you see issues like use-after-free in C++ code that interacts with JS, such as implementations of DOM interfaces, but the issues are not directly JIT related and would be avoided in a fully memory-safe language.

1 more reply

paulmooreparks7y ago

In this case, I mean a subsystem that has been in production since 2006 and has been processing hundreds of thousands of messages a day. I don't claim that it's perfect or bug-free, but if it had significant memory errors I'd have heard about it. I designed and implemented it to use patterns like RAII to manage memory, and it's worked quite well.

gmueckl7y ago

That is why use tools like valgrind to verify that you got it right.

esrauch7y ago

When I worked on a mobile C++ project at Google, we went exceptionally out of our way to avoid memory issues.

We ran under valgrind and multiple sanitizers (and continuously ran those with high coverage unit and integration tests). We ran fuzzers. We had strictly enforced style guides.

We still shipped multiple use after frees and ub-tripping behavior. I also saw multiple issues in other major libraries that we were building from source so it can't be pointed at as just incompetency on my team.

Basically, it might be possible but I think it's exceptionally more difficult to write memory safe C++ than this thread is making it sound.

2 more replies

adrianN7y ago

Together with a test-suite that covers the exponential number of paths through your code...

1 more reply

kibibu7y ago

I haven't written c++ seriously for a number of years. Do you still have to do all that "rule of three" boilerplate stuff to use your classes with the STL? Is it better or worse now with move constructors?

micv7y ago

It's a bit better with C++11 syntax where you can use = delete to remove the default constructors/destructors, e.g.:

  class Class
  {
      Class();
      Class(const Class&) = delete;
      Class& operator = (const Class&) = delete;
      ~Class() = default;
  };

Which I find slightly cleaner than the old approach of declaring them private and not defining an implementation, but the concept hasn't changed much. I'd love a way to say 'no, compiler, I'll define the constructors, operators, and destructors I want - no defaults' but that's not part of the standard.

Move constructors are an extra that, if I remember correctly, don't get a default version, thankfully.

ncmncm7y ago

So, so much better. Nowadays we "use" what has been called "rule of zero". Write a constructor if you maintain an invariant. Rely on library components and destructors for all else.

jcelerier7y ago

> https://jaxenter.com/security-vulnerabilities-languages-1570...

there's a world in terms of safety between C and C++.

comex7y ago

The comparison in that link is pretty meaningless; it scores languages by how many vulnerabilities have been reported in code written in them, without even making an attempt to divide by the total amount of code written in them, let alone account for factors like importance/level of public attention, what role the code plays, bias in the dataset, etc.

eska7y ago

To be fair the report explicitly states this limitation. jcelerier just conveniently forgot to mention it.

eska7y ago

You're misrepresenting the report in order to justify your bias. Direct quote from the report:

    This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behind major infrastructure like Open SSL and the Linux kernel. This winning combination of volume and centrality explains the high number of known open source vulnerabilities in C.`

In other words the report explains this with 1) there being more C code in volume and 2) more C code in security-relevant projects (which are reviewed more by security researchers). It also states explicitly that your conclusion is not to be drawn from this.

majewsky7y ago

Readable version of the quote:

> This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behind major infrastructure like Open SSL and the Linux kernel. This winning combination of volume and centrality explains the high number of known open source vulnerabilities in C.

Please, never ever use code snippets for quotes, unless you hate mobile users. Just put "> " in front.

leetcrew7y ago

> unless you hate mobile users

or just period. I'm reading this on a 4K desktop display, and I still have to scroll. it's only useful for actual code, which is very rarely posted on hn.

j / k navigate · click thread line to collapse

0 comments

vasilipupkin7y ago

I agree with him. in many practical applications with well design class hierarchies it just really isn't much of an issue. Hasn't been for me either.

fetbaffe7y ago

> with well design class hierarchies

:eyes:

vasilipupkin7y ago

ncmncm7y ago

He rolls his eyes at "hierarchies". Libraries do make the difference.

Somebody else interjected Design Patterns. You can define a design pattern as a weakness in your language's ability to express a library function to do the job.

aldanor7y ago

... and with proper use of Design Patterns!

paulmooreparks7y ago

Why is it difficult to believe? I've also written plenty of C++ code without memory bugs. It's not that hard if you play by a few simple rules.

dodobirdlord7y ago

> I've also written plenty of C++ code without memory bugs.

The classic response to this is "That you know of." Consider that even quality-conscious projects with careful code review like Chrome have issues like this use-after-free bug from time to time.

https://googleprojectzero.blogspot.com/2019/04/virtually-unl...

tpolzer7y ago

Chrome is in an exceptionally hard place because of its JIT. Your language cannot tell you if it's safe for your JIT to omit a bounds check.

comex7y ago

1 more reply

paulmooreparks7y ago

gmueckl7y ago

That is why use tools like valgrind to verify that you got it right.

esrauch7y ago

When I worked on a mobile C++ project at Google, we went exceptionally out of our way to avoid memory issues.

We ran under valgrind and multiple sanitizers (and continuously ran those with high coverage unit and integration tests). We ran fuzzers. We had strictly enforced style guides.

Basically, it might be possible but I think it's exceptionally more difficult to write memory safe C++ than this thread is making it sound.

2 more replies

adrianN7y ago

Together with a test-suite that covers the exponential number of paths through your code...

1 more reply

kibibu7y ago

micv7y ago

It's a bit better with C++11 syntax where you can use = delete to remove the default constructors/destructors, e.g.:

  class Class
  {
      Class();
      Class(const Class&) = delete;
      Class& operator = (const Class&) = delete;
      ~Class() = default;
  };

Move constructors are an extra that, if I remember correctly, don't get a default version, thankfully.

ncmncm7y ago

So, so much better. Nowadays we "use" what has been called "rule of zero". Write a constructor if you maintain an invariant. Rely on library components and destructors for all else.

jcelerier7y ago

> https://jaxenter.com/security-vulnerabilities-languages-1570...

there's a world in terms of safety between C and C++.

comex7y ago

eska7y ago

To be fair the report explicitly states this limitation. jcelerier just conveniently forgot to mention it.

eska7y ago

You're misrepresenting the report in order to justify your bias. Direct quote from the report:

    This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behind major infrastructure like Open SSL and the Linux kernel. This winning combination of volume and centrality explains the high number of known open source vulnerabilities in C.`

majewsky7y ago

Readable version of the quote:

Please, never ever use code snippets for quotes, unless you hate mobile users. Just put "> " in front.

leetcrew7y ago

> unless you hate mobile users

or just period. I'm reading this on a 4K desktop display, and I still have to scroll. it's only useful for actual code, which is very rarely posted on hn.

j / k navigate · click thread line to collapse