IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++ • Hacker News Board

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#41

Post by pcwalton » Wed, Dec 16, 2015, 4:44 PM UTC

jbandela1 wrote: post #35

pcwalton wrote: post #24

Earlier quoted context omitted.

Losing memory safety is a pretty big deal though. In particular, the capturing semantics with [&] are going to result in a big surprise (use after free) if you try to close over and capture variables like you do with node.js.

I agree, that it can be a big deal and one must think about ownership and lifetimes whereas in Javascript there is no need to. Especially in code that will exit the surrounding function before the callback is executed, I do not use &, and explicitly specify the captured variables so I can think about what type of capture. However, C++ is improving in this regard. I think lambda capture initializers with C++14 help in…

> I think lambda capture initializers with C++14 help in this regard so that unique_ptr can be used.

They're still opt-in—the burden is on the programmer to get it right.

> In addition, the memory safety tooling is improving - see Herb Sutter's CppCon 2015 keynote.

Sure. But it's not here yet, it requires a lot of annotations, and there are several key unanswered questions that I didn't see an answer to (how the static analysis deals with pointers derived from shared_ptr when it relies on all pointer function parameters being unaliased, for example).

> Finally, C++17 should have co-routines which will make this type of callback code less used and allow one to use "normal" logic without callbacks that will also be non-blocking.

And when the coroutines suspend/yield, you have the exact same issues regarding dangling pointers and use-after-free.

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#42

Post by nickpsecurity » Wed, Dec 16, 2015, 5:59 PM UTC

pjmlp wrote: post #34

seren wrote: post #32

Earlier quoted context omitted.

From what I have seen, the issue is that in big risk-adverse entreprise, the mentality of "don't change anything if it works" goes a bit too far. I feel a bit ashamed, but to give you some rough idea of the age of the toolchain, the c++ compiler we are using does not even support namespace. We are slowly fazing out old platforms but this is really a long drawn struggle. Basically you have to wait that the underlying…

No reason to be ashamed, I have seen many companies that only use platform SDKs (e.g. aC++ on HP-UX) and IT has the last word over what tools are allowed on dev machines. However the situation is no different in other languages. I am aware of some companies still using Java 5 on production, just to cite one example.

I know one major retailer whose terminals are all a DOS variant whose sales ended in 1999 and whose inventory is hard-tied to SCO UNIX. Got future-proof written all over those. ;)

Note: Many key operations, including the backend, are on AS/400 and mainframe. Much wiser choices. Needless to say, the employees tell me that part never goes down.

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#43

Post by nickpsecurity » Wed, Dec 16, 2015, 6:08 PM UTC

pcwalton wrote: post #39

nickpsecurity wrote: post #37

Earlier quoted context omitted.

Exactly. There's attacks on them posted quite regularly.

Note the emphasis on accidental memory safety violations. There's an enormous difference between attackers running JavaScript that they control and attackers having to exploit memory safety issues in JavaScript that you wrote. Virtually all attacks against JavaScript JITs have been of the former type, in that they rely on perfectly crafted hostile JavaScript that nobody would write on purpose. But in a node.js type o…

"Note the emphasis on accidental memory safety violations."

Good points. Of course, I'm guessing you're saying it's still really hard to write memory-safe code with modern C++ constructs whereas others here suggest it's pretty easy. That point is tripping me up in these discussions. Did a quick Google on C++ safety and found you already said something about the topic:

https://news.ycombinator.com/item?id=7587978

My statement is predicated on the premise that modern C++ can be done safely without issues like that. If not, then it's false and we're back to me recommending safer, systems languages.

One thing to remember, though, is that there's tools to automatically transform C code into safe code. Softbound + CETS comes to mind. Might be able to use a C++-to-C compiler with one of those. There's also safer forms of C++ like Ironclad C++.

http://www.cs.grinnell.edu/~osera/papers/ironclad-cc.pdf

So, the situation might be worse than people looking into C++ were hoping but not as bad as you think.

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#44

Post by pjmlp » Wed, Dec 16, 2015, 9:13 PM UTC

pcwalton wrote: post #40

pjmlp wrote: post #31

Earlier quoted context omitted.

To add my input to pcwalton. It is true that modern C++ with the proper tools can mitigate many of the issues that come from C heritage. The sad reality is that despite the tools that C++ offers for memory safety, the majority of enterprise developers don't buy into them and the code looks more like C with classes than anything else. If you look at CppCon 2015 when Herb was presenting the Core Guidelines and the new…

> If you look at CppCon 2015 when Herb was presenting the Core Guidelines and the new VSC++ static analyzers, only 1% of the audience said they ever used one. That's interesting. It's especially interesting to note that those static analyzers work on unmodified code! The work-in-progress ISO Core C++ lifetime profile does not work on unmodified code and requires a lot of annotations…

Here

CppCon 2015: Herb Sutter "Writing Good C++14... By Default" around 00:32:00.

https://youtu.be/hEx5DNLWGgA?t=2053

> The work-in-progress ISO Core C++ lifetime profile does not work on unmodified code and requires a lot of annotations…

Herb mentions that it still less than lifetimes in Rust given C++'s type system:

https://youtu.be/hEx5DNLWGgA?t=1653

https://github.com/isocpp/CppCoreGuidelines/raw/09aef9bd86d9...

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#45

Post by pcwalton » Wed, Dec 16, 2015, 10:27 PM UTC

pjmlp wrote: post #44

pcwalton wrote: post #40

Earlier quoted context omitted.

> If you look at CppCon 2015 when Herb was presenting the Core Guidelines and the new VSC++ static analyzers, only 1% of the audience said they ever used one. That's interesting. It's especially interesting to note that those static analyzers work on unmodified code! The work-in-progress ISO Core C++ lifetime profile does not work on unmodified code and requires a lot of annotations…

Here CppCon 2015: Herb Sutter "Writing Good C++14... By Default" around 00:32:00. https://youtu.be/hEx5DNLWGgA?t=2053 > The work-in-progress ISO Core C++ lifetime profile does not work on unmodified code and requires a lot of annotations… Herb mentions that it still less than lifetimes in Rust given C++'s type system: https://youtu.be/hEx5DNLWGgA?t=1653 https://github.com/isocpp/CppCoreGuidelines/raw/09aef9bd86d9...

I've read the paper closely.

> Herb mentions that it still less than lifetimes in Rust given C++'s type system:

Yes, I know Herb claimed that. As far as any of us can tell, it's based on a misunderstanding of Rust's rules and is wrong :)