61–70 of 88 posts
Earlier quoted context omitted.
A significant fraction of major security vulnerabilities in C/C++ codebases relate to memory-management bugs.
How old is the code though? It's actually really hard to get modern C++ wrong
https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary...
Earlier quoted context omitted.
A significant fraction of major security vulnerabilities in C/C++ codebases relate to memory-management bugs.
How old is the code though? It's actually really hard to get modern C++ wrong
That's not true. The language is full of footguns, from its basic expressions (signed overflow, integer division-by-zero, and read-before-write are all undefined behaviour) up to concurrency (data-races are undefined behaviour) and everything in between (unsafe arrays, unsafe memory management, alignment, the list goes on). The high-level constructs in modern C++ help, but you're never further than one misstep from undefined behaviour.
Even high-profile codebases by highly skilled teams using all the modern tools, still run into trouble. Even Chromium has security issues arising from the dangers of C++. The push for Rust is out of pragmatism, not trend-chasing or theoretical purity.
Of course, C codebases like the Linux kernel also continue to have these issues.
Earlier quoted context omitted.
How old is the code though? It's actually really hard to get modern C++ wrong
Assuming it gets used. https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary...
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...
Like I said, human-readable HTTP needs to die, but it's far too late.
C++'s networking support is one of its greatest shortcomings. If I had the choice, I'd never use ASIO again and just use libuv. Coroutines look interesting, I just need to get my head around them. All code examples I've seen, just as with ASIO, deal with the happy path only. For example, there's hardly a mention of timeouts and the faff ASIO makes you do to get them to work. If there's no 'read(..., timeout)' functio…
Boost Beast, which is built on ASIO, has support for timeouts[0], as well as HTTP 1.1 and Websockets. The examples in the Beast tree do do some pretty complex stuff elegantly, like a multi-client chat server[1], so it's possible. There's also nghttp2_asio, built on nghttp2, which supports HTTP/2[2]. Overall I agree though that ASIO is a very complex and very low level, and it's a lot of work to use it well. Sometimes…
Our use case sends thousands of requests per second per machine.
Earlier quoted context omitted.
That portability to a zillion platforms was part of the language design, though. 'Portable assembler' and all that.
All high level languages are portable, and many already were before C came to be. Just marketing speak.
There's a gaping hole in the abstraction when it comes to word size, but that's about it, and it's obvious to diagnose at least.
Compared to the list of languages above with their more advanced features, it's super easy to port a C compiler and start compiling code. Worse is better.
Earlier quoted context omitted.
All high level languages are portable, and many already were before C came to be. Just marketing speak.
Sure, with more or less effort. C's semantics seem very easy to port, with very little abstraction over the commonalities that all (most?) assemblies share: computer as a giant array with a CPU and registers. There's a gaping hole in the abstraction when it comes to word size, but that's about it, and it's obvious to diagnose at least. Compared to the list of languages above with their more advanced features, it's su…
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.
Chromium is a good example actually, I bet they would rather follow the "Custom C++ libraries" and "Hardware mitigations" than the Firefox approach.
https://www.chromium.org/Home/chromium-security/memory-safet...
Apple did something similar recently, their iBoot firmware uses a custom safe C dialect.
Earlier quoted context omitted.
Sure, with more or less effort. C's semantics seem very easy to port, with very little abstraction over the commonalities that all (most?) assemblies share: computer as a giant array with a CPU and registers. There's a gaping hole in the abstraction when it comes to word size, but that's about it, and it's obvious to diagnose at least. Compared to the list of languages above with their more advanced features, it's su…
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.
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 accident here as well, but no other language/OS combo ran on like 12 different architectures in the 80s.
Earlier quoted context omitted.
The late pioneer in compiler optimization--Frances Allen--agrees. 2006: "..but something else had happened--and that was back in 1973--[something] which I was very, very unhappy about--and that was the advent of C! It derailed, as far as I was concerned, the advances that I foresaw in compilers. One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data-…
> 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…