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

Dalin – A C++ non-blocking network library on Linux

github.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Dalin – A C++ non-blocking network library on Linux

#41

Post by pjmlp »

huhtenberg wrote: post #40
pjmlp wrote: post #26

Earlier quoted context omitted.

Usually those are the projects where CVEs are a common feature..

... as are the projects that overdo on "modern C++" to the extent of introducing even more severe problems masked by the layers of needless abstraction. CVEs don't come from C or C++. They come from the lack of coding discipline and with all other things being equal C programmers are generally better skilled and more diligent than their C++ counterparts.

> C programmers are generally better skilled and more diligent than their C++ counterparts.

That is not what the CVEs on Linux prove.

https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...

One would expect, on a C project with the rigor of review process that patches go through and the usual assement I keep hearing since the early 90's about C programmer skills, now repeated again by you, that Linux would have 0 CVEs reported.

The majority of exploits in C++ are related to its copy-paste compatibility with C, and devs that insist in using them in spite of the language offering safer, better, alternatives.

Re: Dalin – A C++ non-blocking network library on Linux

#42

Post by ryl00 »

Matthias247 wrote: post #36
johannes1234321 wrote: post #16

From a short review I don't like this much. - It's containing it's own abstraction over pthread instead of std::thread/std::mutex/... - It passes shared_ptr via reference (yeah, this saves an increment and decrement on the refcounting, but the code is not tuned that much) - it prints directly to sterr (via fprintf) making it hard to redirect errors somewhere else - It seems not to be prepared to be ported to other pl…

I agree with the last sentence. Nevertheless, if it's mainly a learning project for the author, I don't think there's anything wrong with writing it. Some technical review for the presented library: - It doesn't seem to support any kind of backpressure, which is basically a nogo if you want to build something reliable on top. On the receiving side you will always get data pushed via callbacks without the possibility…

Recently modified a legacy C++ program at work that was using 'bare' socket code, that now needed to support multiple connections. First approach using Asio worked, but as you mentioned involved scattering logic in various callbacks and transferring state around everywhere. And that was just the 'pure' connection establishment code; the business logic part of things also needed to occasionally do comm, and it wasn't really viable to rip up the legacy call hierarchy to convert things into callback form.

Enter Asio + stackful coroutines. Migrating the old business logic was nearly effortless. Just had to be wary of accidentally blowing the stack, and watch for exceptions in the various coroutines' mains. But otherwise able to preserve all that old, functioning code while meeting the new requirements.

Re: Dalin – A C++ non-blocking network library on Linux

#44

Post by ioquatix »

ryl00 wrote: post #42
Matthias247 wrote: post #36

Earlier quoted context omitted.

I agree with the last sentence. Nevertheless, if it's mainly a learning project for the author, I don't think there's anything wrong with writing it. Some technical review for the presented library: - It doesn't seem to support any kind of backpressure, which is basically a nogo if you want to build something reliable on top. On the receiving side you will always get data pushed via callbacks without the possibility…

Recently modified a legacy C++ program at work that was using 'bare' socket code, that now needed to support multiple connections. First approach using Asio worked, but as you mentioned involved scattering logic in various callbacks and transferring state around everywhere. And that was just the 'pure' connection establishment code; the business logic part of things also needed to occasionally do comm, and it wasn't…

I love that we came to the same conclusion. https://github.com/kurocha/async

Re: Dalin – A C++ non-blocking network library on Linux

#45

Post by huhtenberg »

pjmlp wrote: post #41
huhtenberg wrote: post #40

Earlier quoted context omitted.

... as are the projects that overdo on "modern C++" to the extent of introducing even more severe problems masked by the layers of needless abstraction. CVEs don't come from C or C++. They come from the lack of coding discipline and with all other things being equal C programmers are generally better skilled and more diligent than their C++ counterparts.

> C programmers are generally better skilled and more diligent than their C++ counterparts. That is not what the CVEs on Linux prove. https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... One would expect, on a C project with the rigor of review process that patches go through and the usual assement I keep hearing since the early 90's about C programmer skills, now repeated again by you, that Linux would ha…

> That is not what the CVEs on Linux prove.

You picked one of the largest, complex and most scrutinized C projects of the whole time and compared its CVE count... to what exactly?

Re: Dalin – A C++ non-blocking network library on Linux

#46

Post by pjmlp »

huhtenberg wrote: post #45
pjmlp wrote: post #41

Earlier quoted context omitted.

> C programmers are generally better skilled and more diligent than their C++ counterparts. That is not what the CVEs on Linux prove. https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... One would expect, on a C project with the rigor of review process that patches go through and the usual assement I keep hearing since the early 90's about C programmer skills, now repeated again by you, that Linux would ha…

> That is not what the CVEs on Linux prove. You picked one of the largest, complex and most scrutinized C projects of the whole time and compared its CVE count... to what exactly?

Exactly because it is "largest, complex and most scrutinized C projects of the whole time" and yet it is impossible to use C without producing a couple of CVEs every single month.

And a good example against the myth that the skilled C programmer that doens't produce memory corruption exists.

Re: Dalin – A C++ non-blocking network library on Linux

#47

Post by huhtenberg »

pjmlp wrote: post #46
huhtenberg wrote: post #45

Earlier quoted context omitted.

> That is not what the CVEs on Linux prove. You picked one of the largest, complex and most scrutinized C projects of the whole time and compared its CVE count... to what exactly?

Exactly because it is "largest, complex and most scrutinized C projects of the whole time" and yet it is impossible to use C without producing a couple of CVEs every single month. And a good example against the myth that the skilled C programmer that doens't produce memory corruption exists.

> Exactly

Again - what are you comparing Linux CVE counts to?

You can't point at an absolute count for A while arguing that A is inferior to B. I see nothing to support the assumption that a Linux-sized project in C++ would've have any less of CVEs.

> the myth that the skilled C programmer that doens't produce memory corruption exists.

Don't put words in my mouth. You are refuting a point that I didn't make. I said that C programmers are generally better skilled than C++ ones, which is not a "myth".

Re: Dalin – A C++ non-blocking network library on Linux

#48

Post by Matthias247 »

ryl00 wrote: post #42
Matthias247 wrote: post #36

Earlier quoted context omitted.

I agree with the last sentence. Nevertheless, if it's mainly a learning project for the author, I don't think there's anything wrong with writing it. Some technical review for the presented library: - It doesn't seem to support any kind of backpressure, which is basically a nogo if you want to build something reliable on top. On the receiving side you will always get data pushed via callbacks without the possibility…

Recently modified a legacy C++ program at work that was using 'bare' socket code, that now needed to support multiple connections. First approach using Asio worked, but as you mentioned involved scattering logic in various callbacks and transferring state around everywhere. And that was just the 'pure' connection establishment code; the business logic part of things also needed to occasionally do comm, and it wasn't…

Which coroutine library did you went for? Boost fiber? I want to explore that at some time, but couldn't use it in my main asio project since that requires support for older boost versions and ideally also for obscurer platforms.

Good to hear that you had a good experience with that approach.

Re: Dalin – A C++ non-blocking network library on Linux

#49

Post by pjmlp »

huhtenberg wrote: post #47
pjmlp wrote: post #46

Earlier quoted context omitted.

Exactly because it is "largest, complex and most scrutinized C projects of the whole time" and yet it is impossible to use C without producing a couple of CVEs every single month. And a good example against the myth that the skilled C programmer that doens't produce memory corruption exists.

> Exactly Again - what are you comparing Linux CVE counts to? You can't point at an absolute count for A while arguing that A is inferior to B. I see nothing to support the assumption that a Linux-sized project in C++ would've have any less of CVEs. > the myth that the skilled C programmer that doens't produce memory corruption exists. Don't put words in my mouth. You are refuting a point that I didn't make. I said t…

> I said that C programmers are generally better skilled than C++ ones, which is not a "myth".

So where are those statistic results available?

Every single memory corruption in C++ code can be traced back at language semantics inherited from C, thus common to both languages.

Which aren't present in C++ code bases where developers adopt C++ best practices, meaning eschewing the majority of C programming pattern, while adopting std library types, references instead of pointers, class enumerations instead of plain enums, classes to keep struct invariants, ....

History has proven on its CVE databases that the majority of C devs are not skilled at all to care about writing safe code.

Whereas one of the major points done by ANSI C++ members work is how to reduce UB use cases and reduce the possibilities of exploits, the ANSI C members decided to turn ANNEX K into an optional item in C11, and VLAs have been proven to be quite nice for stack attacks, thus not even considered for ANSI C++ adoption.

Re: Dalin – A C++ non-blocking network library on Linux

#50

Post by jcelerier »

pzone wrote: post #39
jcelerier wrote: post #22

Earlier quoted context omitted.

so do you also not use std::unordered_map, std::shared_ptr, std::thread, std::regex, or std::mutex ? because they all come from boost.

Once they're safely out of Boost and implemented by the stdlib they're an order of magnitude more convenient to use. You can also be more confident in their future stability.

> Once they're safely out of Boost and implemented by the stdlib they're an order of magnitude more convenient to use.

I don't understand this. Most of the time the API doesn't even change; you can just do `namespace lib = std` or `namespace lib = boost` according to which one you want to use. In my own code for instance I have a header where I choose the std::, std::experimental or boost:: version of `optional`, `string_view`, and `any` according to the recentness of the stdlib I'm using; nothing else is needed.

Post reply on HN