You can use std containers in a no-exceptions environment. Just know that if an error occurs the program will terminate.

We've banned exceptions! If any occur, we just don't catch them.

Of course you can, you just need to check your preconditions and limit sizes ahead of time - but you need to do that with exceptions too because modern operating systems overcommit instead of failing allocations and the OOM killer is not going to give you an exception to handle.

I don't think it would be typical to depend on exception handling when dealing with boundary conditions with C++ containers.

I mean .at is great and all, but it's really for the benefit of eliminating undefined behavior and if the program just terminates then you've achieved this. I've seen decoders that just catch the std::out_of_range or even std::exception to handle the remaining bugs in the logic, though.

checksec is part of the pwntools suite. Along with other tools for finding ROP gadgets and shellcode generation.

The most shocking part is the absence of stack canaries. I know there are issues with them on microcontrollers, but still I would assume they’re enabled by default by the compiler.

Python, rust and Go aren’t beacons of software stability though.

Zig’s general purpose allocator might detect use after free in debug builds, however zig appears to be ok with dangling (invalidated) pointers/slices and use after free for stack variables, which is more concerning, especially from a security standpoint.

```zig

const std = @import("std");

fn get_ptr() i32 { var a: i32 = 6; return &a; }

pub fn main() void {

    var x: ?*i32 = undefined;
    {
        var a: i32 = 5;
        x.? = &a;
    }
    std.debug.print("{} {}", .{ x.?.*, get_ptr().* });

}

``` These are trivial examples that Zig doesn’t even warn about, even though similar code in C or C++ gets a warning in gcc and clang.

This discussion:

https://ziggit.dev/t/what-makes-ban-returning-pointer-to-sta...

indicates that core zig devs aren’t interested in diagnosing such usage.

But it does. He has to notify R4L of what his changes were and how it broke the Rust driver. Even if he didn’t, he will still be contacted for information regarding these things.

He does not have to notify them.

> he will still be contacted for information regarding these things.

Just like any other user, and he is free to ignore them just like any other person doing so.

How is that different from any C driver currently in existence? Notifying API consumers of what is changing and how and answering the occasional is absolute table stakes for any software developer and throwing a tantrum about that is incredibly juvenile.

I am not willing to pass a value judgement on his decision to do this, but I do agree that I don't think it ended up being helpful to R4L.

Flash apps and Java applets (via Cheerp) can run again in browsers thanks to wasm.

I imagine this would be possible with just JavaScript. It would probably run somewhat slower than WASM, but still, it's possible to transpile Rust to JavaScript. [0]

[0] https://en.wikipedia.org/wiki/Asm.js#Programming_languages

If it's a little Java application, you can also port it to Dart, they share a lot of similarities. I did this and it was quite easy, but in my case, it was a little javafx application that drew to the canvas, not many dependencies where used.

Embrace, Extend, Extinguish, Endow

> It is undoubtedly hard work to fix these remaining problems, as they typically require both rust and C knowledge in addition to deep HTTP familiarity. There does not seem to be that many persons interested or available for this challenge. Meanwhile, there is little if any demand for hyper from existing (lib)curl users.

You might as well replace HTTP with OS, hyper with rust and curl with linux, and you get the current situation with Rust adoption on Linux.