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

A Universal I/O Abstraction for C++ (2020)

cor3ntin.github.io

Post reply on HN
Print view View original

71–80 of 88 posts

Re: A Universal I/O Abstraction for C++ (2020)

#71

Post by pjmlp »

refenestrator wrote: post #69
pjmlp wrote: post #67

Earlier quoted context omitted.

So easy that to actually make C portable, UNIX had to be made into a C standard library via POSIX, otherwise portable C code is basically just logic and data structures.

Sure, but the flipside of that is that UNIX itself is fairly easy to port to a new CPU, due to being mostly written in C. So port your compiler, figure out a syscall interface on your CPU, patch it into unix/libc and compile them, and.. it's not like that's a small amount of work but it's way easier than bootstrapping any other environment from scratch on a new architecture. There's surely some amount of historical a…

Because no other timesharing OS was available in free beer source code for others to port it, it had nothing to do with C.

Re: A Universal I/O Abstraction for C++ (2020)

#72

Post by v8dev123 »

nly wrote: post #60
v8dev123 wrote: post #35

Earlier quoted context omitted.

You might love evpp instead ASIO. It's just pain to install it but once you do it's a heaven. As for HTTP parsing, llhttp does great job. It however lack multipart parsing.

Boost.Beast has its own HTTP parser[0], during the development of which Vinnie Falco (the principle author of Beast) found many bugs/inconsistencies in Node.js's own parser[1]. Personally I'd rather use this than something based on Node.js http-parser. [0] https://www.boost.org/doc/libs/develop/libs/beast/doc/html/b... [1] https://github.com/nodejs/http-parser/issues?q=is%3Aissue+au...

llhttp different from the original http-parser. It has lesser bugs because it's written in Typescript which transpiled to C and it's faster than the original http-parser

Re: A Universal I/O Abstraction for C++ (2020)

#73

Post by v8dev123 »

MaxBarraclough wrote: post #63
pjmlp wrote: post #61

Earlier quoted context omitted.

Assuming it gets used. https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary...

I'm less optimistic. Even major C++ projects that do everything right, still have issues that would have been prevented had they used a safe language. My go-to example is Chromium.

Rust doesn't prevents logical bugs. Chromium had plenty of those. Most are capable of RCE. They were more dangerous than memory ones because they bypass sandbox in one-click.

As for Windows, The Russians exploited a logical bug in kernel for privilege escalation.

Rust also doesn't prevents overflows, DoS, UaF, OOB.

For example, see CVE-2018-1000657

Another dangerous thing about Rust is Crates. Crates doesn't audit packages for malware and you will face far worse than NPM like situation in future.

Re: A Universal I/O Abstraction for C++ (2020)

#74

Post by MaxBarraclough »

v8dev123 wrote: post #73
MaxBarraclough wrote: post #63

Earlier quoted context omitted.

I'm less optimistic. Even major C++ projects that do everything right, still have issues that would have been prevented had they used a safe language. My go-to example is Chromium.

Rust doesn't prevents logical bugs. Chromium had plenty of those. Most are capable of RCE. They were more dangerous than memory ones because they bypass sandbox in one-click. As for Windows, The Russians exploited a logical bug in kernel for privilege escalation. Rust also doesn't prevents overflows, DoS, UaF, OOB. For example, see CVE-2018-1000657 Another dangerous thing about Rust is Crates. Crates doesn't audit pa…

> Rust doesn't prevents logical bugs. Chromium had plenty of those.

Right, but that's not the goalpost we're discussing. We're talking about languages that can guarantee safety - the absence of undefined behaviour - not languages that can fully guarantee correctness (e.g. SPARK).

> Rust also doesn't prevents overflows, DoS, UaF, OOB.

In Rust, integer overflow does not cause undefined behaviour. In Safe Rust, undefined behaviour cannot arise from buffer overflows, use-after-free, or out-of-bounds array access. Safe Rust precludes all undefined behaviour, after all. Unsafe Rust may be 'more safe' than C++ in degree, but not in category: it's an unsafe language, as you say.

> Another dangerous thing about Rust is Crates.

Again, sure.

Re: A Universal I/O Abstraction for C++ (2020)

#75

Post by v8dev123 »

MaxBarraclough wrote: post #74
v8dev123 wrote: post #73

Earlier quoted context omitted.

Rust doesn't prevents logical bugs. Chromium had plenty of those. Most are capable of RCE. They were more dangerous than memory ones because they bypass sandbox in one-click. As for Windows, The Russians exploited a logical bug in kernel for privilege escalation. Rust also doesn't prevents overflows, DoS, UaF, OOB. For example, see CVE-2018-1000657 Another dangerous thing about Rust is Crates. Crates doesn't audit pa…

> Rust doesn't prevents logical bugs. Chromium had plenty of those. Right, but that's not the goalpost we're discussing. We're talking about languages that can guarantee safety - the absence of undefined behaviour - not languages that can fully guarantee correctness (e.g. SPARK). > Rust also doesn't prevents overflows, DoS, UaF, OOB. In Rust, integer overflow does not cause undefined behaviour. In Safe Rust, undefine…

> integer overflow does not cause undefined behavior

Source please?

I ask this since Rust doesn't have a formal specification and I can't keep up with it's inner changes.

It did cause undefined behavior in my case but that was 4 years ago.

Re: A Universal I/O Abstraction for C++ (2020)

#76

Post by steveklabnik »

v8dev123 wrote: post #75
MaxBarraclough wrote: post #74

Earlier quoted context omitted.

> Rust doesn't prevents logical bugs. Chromium had plenty of those. Right, but that's not the goalpost we're discussing. We're talking about languages that can guarantee safety - the absence of undefined behaviour - not languages that can fully guarantee correctness (e.g. SPARK). > Rust also doesn't prevents overflows, DoS, UaF, OOB. In Rust, integer overflow does not cause undefined behaviour. In Safe Rust, undefine…

> integer overflow does not cause undefined behavior Source please? I ask this since Rust doesn't have a formal specification and I can't keep up with it's inner changes. It did cause undefined behavior in my case but that was 4 years ago.

It wasn’t undefined behavior four years ago either. RFC 560, from 2014, defines this behavior. As far as I can recall, this was mostly a codification of what was already in place; I’m pretty sure it was never UB.

Re: A Universal I/O Abstraction for C++ (2020)

#77

Post by MaxBarraclough »

v8dev123 wrote: post #75
MaxBarraclough wrote: post #74

Earlier quoted context omitted.

> Rust doesn't prevents logical bugs. Chromium had plenty of those. Right, but that's not the goalpost we're discussing. We're talking about languages that can guarantee safety - the absence of undefined behaviour - not languages that can fully guarantee correctness (e.g. SPARK). > Rust also doesn't prevents overflows, DoS, UaF, OOB. In Rust, integer overflow does not cause undefined behaviour. In Safe Rust, undefine…

> integer overflow does not cause undefined behavior Source please? I ask this since Rust doesn't have a formal specification and I can't keep up with it's inner changes. It did cause undefined behavior in my case but that was 4 years ago.

Here's a source. [0] In release builds, overflow results in two's complement wrapping. In debug builds, it results in a panic at runtime. It never results in undefined behaviour.

Safe Rust really is a safe language. That's really what's remarkable about Rust: it has high ambitions for safety and usability and performance, and it's succeeding in achieving them.

(I hear there are some who want to dilute the safety guarantees of Safe Rust. I'm optimistic that they will continue to be ignored.)

[0] https://doc.rust-lang.org/book/ch03-02-data-types.html#integ...

Re: A Universal I/O Abstraction for C++ (2020)

#78

Post by v8dev123 »

MaxBarraclough wrote: post #77
v8dev123 wrote: post #75

Earlier quoted context omitted.

> integer overflow does not cause undefined behavior Source please? I ask this since Rust doesn't have a formal specification and I can't keep up with it's inner changes. It did cause undefined behavior in my case but that was 4 years ago.

Here's a source. [0] In release builds, overflow results in two's complement wrapping. In debug builds, it results in a panic at runtime. It never results in undefined behaviour. Safe Rust really is a safe language. That's really what's remarkable about Rust: it has high ambitions for safety and usability and performance, and it's succeeding in achieving them. (I hear there are some who want to dilute the safety guar…

> Relying on integer overflow’s wrapping behavior is considered an error

Your doc also says this.

> I hear there are some who want to dilute the safety guarantees of Safe Rust

Unfortunately, I don't use Rust at work. I can't talk about it anymore, either. I can't use an informal reference to reason about its actual behavior. At the end of the day, C++ puts food on the table. I try to improve C++ as much as possible, knowing that it is an imperfect language. C++ is heading into safe direction, and I'm sure C++26 will be able to provide more features to write code safely.

Rust seriously need to add Function Overloading, Generics.

Re: A Universal I/O Abstraction for C++ (2020)

#79

Post by flukus »

oldmanhorton wrote: post #70
flukus wrote: post #23

Earlier quoted context omitted.

> One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally." Well 50 years on we still haven't seen any of these "sufficiently smart compilers", at best they can outsmart C compilers in a few cases with things like generics, so the idea that higher level languages would…

Unfortunately, this assumes everyone is a master at C and that we are comparing straight line speed. In the real world, higher level languages have a much better comparison since everyone's C program has their own slow, buggy "standard" library instead of the hyper optimized ones of higher level languages. One of the major reasons why that is the case is because C, at a language design level, makes building those kin…

> In the real world, higher level languages have a much better comparison since everyone's C program has their own slow, buggy "standard" library instead of the hyper optimized ones of higher level languages.

In the real world we've pissed away 30 years of hardware improvements primarily through switching to higher level languages. In the real world higher level languages are still not used we're performance counts (like games). In the real world low level languages like c and C++ are still powering our most important and fundamental projects.

Re: A Universal I/O Abstraction for C++ (2020)

#80

Post by pjmlp »

flukus wrote: post #79
oldmanhorton wrote: post #70

Earlier quoted context omitted.

Unfortunately, this assumes everyone is a master at C and that we are comparing straight line speed. In the real world, higher level languages have a much better comparison since everyone's C program has their own slow, buggy "standard" library instead of the hyper optimized ones of higher level languages. One of the major reasons why that is the case is because C, at a language design level, makes building those kin…

> In the real world, higher level languages have a much better comparison since everyone's C program has their own slow, buggy "standard" library instead of the hyper optimized ones of higher level languages. In the real world we've pissed away 30 years of hardware improvements primarily through switching to higher level languages. In the real world higher level languages are still not used we're performance counts (…

In real world politics also count higher than techinical capabilities.

Source, replacing GUI and distributed applications written in C and C++ with managed languages (AOT and JIT) for the last 20 years.

Post reply on HN