Earlier quoted context omitted.
A lot of industrial automation was built with an offline usecase in mind. Then someone invented the IIoT.
The Internet Internet of Things?
IIoT stands for "Industrial Internet of Things"
The Case for Memory Safe Roadmaps
401–410 of 427 posts
Re: The Case for Memory Safe Roadmaps
#402Earlier quoted context omitted.
What is the "this" referred to here?
The title of the post: using memory-safe languages.
So it's your contention that the comment should read, "At least my usecase has C completely disconnected from the internet. I have no idea how [using memory-safe languages] is going to work at the OS level."
I struggle to understand the comment. Do these two sentences relate to one another or is the second one a non-sequitur?
Re: The Case for Memory Safe Roadmaps
#403In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials from the community - tons of legacy code all using C++. https://github.com/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to buil…
Importantly, if you look at lists of "C/C++" security holes, you find it is almost all C security holes. So when they write "C/C++" they are hoping you won't notice they are lying to you. The residue of holes in C++ code is about the same as JS, Python, etc. So just eliminating C and C-like constructs gets you to the same level of security as the other languages.
The way you have phrased this is very disingenuous.
> Importantly, if you look at lists of "C/C++" security holes, you find it is almost all C security holes. So when they write "C/C++" they are hoping you won't notice they are lying to you.
As these "C-isms" are part of the base language, and you cant 'opt out', this means the base language is still included in the lists. Most C++ applications still linked (and used symbols from) the system libc runtime.
I do not write C++ with any regularity, because I like my C footguns and dont want additional layers of footguns in my code. last time I tried writing C++, it allowed you to use after free, access raw memory pointers with no validation, iterate off the end of arrays and integer overflow and underflow, all without using "C" style constructs.
Maybe it has changed, maybe C++ is now not as insane as it used to be and smart auto magic pointers solve everything. I'd love to read about how modern C++ solves these issues, do you have any resources ?
Re: The Case for Memory Safe Roadmaps
#404In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials from the community - tons of legacy code all using C++. https://github.com/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to buil…
In theory, I love the idea of rust. I'd probably like actually using it on real projects... but I don't have any use case.
My only interactions with compiled languages all have legacy constraints, or involve someone else's project.
ESP32 seems to have lots of Rust support work happening, so I can very easily imagine switching in a few years though.
If I had a reason to write a new performance-critical non-embedded app I'd probably use Rust.
Re: The Case for Memory Safe Roadmaps
#405Earlier quoted context omitted.
Really, the only memory unsafe languages still in use are C and C++. If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. "Rewrite it in Rust" gets a bit of pushback, perhaps even justified, but at this point in time I'll take anything that just reduces that behemoth in size. The journey of a thousand mil…
> If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. It is not only or even mostly legacy. I'm a systems programmer (in classical sense, not "but my web service is soooo highly loaded and scalable that I will call it systems programming!") and from what I see on the job people start new projects in C an…
Why do they choose C/C++? Is it just what they and their colleagues already know and nobody wants to be the one to push for change? Easier integration with other C/C++ stuff?
Re: The Case for Memory Safe Roadmaps
#406Re: The Case for Memory Safe Roadmaps
#407Given the vast amount of C/C++ around, much which will never be rewritten, I wonder if bounds checking compilers should be considered?
We've had bound checks and address sanitizers in most C compilers for years now at this point (gcc, tcc, clang)
Re: The Case for Memory Safe Roadmaps
#408Earlier quoted context omitted.
You can have underflow/overflow trapping today if you want it in C++. Most people don't use it, at least not in release builds, because of the performance cost.
It doesn't catch all signed overflow. If you define a function like this: int8_t abs8(int8_t n) { return (n >= 0) ? n : -n; } Even with `-ftrapv`, evaluating abs8(-128) will produce -128, because 127 is the maximum value for a signed 8-bit integer (so trying to get 128 wraps around to -128), but this isn't caught. However, both Rust and Ada do catch this. This article highlights this difference between C and Ada: htt…
I wasn’t necessarily assuming ‘-ftrapv’. For reliable software in C++ it is pretty common to have alternative integer type implementations that provide different fully defined behaviors and guarantees than the default integer types. This became legitimately transparent around C++17 IIRC. It is more or less drop-in and mostly produces optimal codegen. Also a good way to eliminate irritating integer behaviors inherited from C.
It is easy enough to crank out custom integer types in C++ these days which are arbitrarily safe that there isn’t much excuse for not doing it, particularly since generics and metaprogramming does most of the work. Outside of interfacing with syscalls, there isn’t much use for C primitives beyond size_t.
Re: The Case for Memory Safe Roadmaps
#409Earlier quoted context omitted.
There are categories of software for which C++ is still the clear best choice due to its superior expressiveness as a systems language. There are also other types of safety beyond memory safety that are better supported in C++ than other systems languages. As a practical matter I haven't seen a pointer issue in years, working from a C++17 foundation, so the expressiveness and other safety benefits are more valuable t…
> There are also other types of safety beyond memory safety that are better supported in C++ than other systems languages. Such as? Genuinely curious.
C++20 has very powerful compile-time metaprogramming and generics facilities. As a consequence, you can codegen complex systems of data structures and algorithms that are verified to be both optimal and safe at compile-time, essentially from a specification. The ability to automagically infer and codegen use-case specific types means that there are almost no naked primitive ‘int’ and similar types anywhere, the types are restricted to what they need to express and little more. While there is some ability to formally verify the correctness of these type interactions at compile-time, it is limited as a practical matter. The real strength is the ability verify the properties pretty exhaustively at runtime, given sufficiently good testing.
If you implement something like a database kernel almost entirely in user space, which is what you want to do if you care about performance, you have a new set of problems that languages like Rust were not designed to solve. Ownership, mutability, and lifetimes are not resolvable for most objects at compile-time, they can only be resolved dynamically at runtime. With C++, you can make these look like ordinary objects with ordinary behaviors, with metaprogramming abstractions under the hood arbitrating the chaos. Things that look unsafe are actually guaranteed safe by the underlying abstractions. In this type of software, almost your entire address space is “unsafe” in some way, so it is enormously useful to be able to overlay a safety model that does not rely on the compiler, since the compiler cannot solve these cases.
I use both C++ and Rust in production environments. There are cases where C++ used well is legitimately safer, theoretically and empirically, which is why I still use C++ for some things. Rust may become stronger at dealing with these cases but it still has many years to go. (Also, Rust async story is a hot mess, and you really need async for scalable, performant systems software.)
Re: The Case for Memory Safe Roadmaps
#410Earlier quoted context omitted.
It doesn't catch all signed overflow. If you define a function like this: int8_t abs8(int8_t n) { return (n >= 0) ? n : -n; } Even with `-ftrapv`, evaluating abs8(-128) will produce -128, because 127 is the maximum value for a signed 8-bit integer (so trying to get 128 wraps around to -128), but this isn't caught. However, both Rust and Ada do catch this. This article highlights this difference between C and Ada: htt…
I wasn’t necessarily assuming ‘-ftrapv’. For reliable software in C++ it is pretty common to have alternative integer type implementations that provide different fully defined behaviors and guarantees than the default integer types. This became legitimately transparent around C++17 IIRC. It is more or less drop-in and mostly produces optimal codegen. Also a good way to eliminate irritating integer behaviors inherited…
> For reliable software in C++ it is pretty common to have alternative integer type implementations that provide different fully defined behaviors and guarantees than the default integer types. This became legitimately transparent around C++17 IIRC. It is more or less drop-in and mostly produces optimal codegen. Also a good way to eliminate irritating integer behaviors inherited from C.
I didn't know this. I can imagine you can create your own integer types as wrappers over existing primitives, and define them so that, e.g., on signed overflow, the program aborts or wraps (and your signed integers are actually a wrapper class over unsigned integers, but with operator overloading so that they act like signed integers). Is that what you mean? If not, could you show me what you mean?