withoutboats3 (u/withoutboats3)

withoutboats3 commented on Memory Safety for Skeptics queue.acm.org/detail.cfm?... · Posted by u/steveklabnik

kazinator · a month ago

It's hard to imagine that if a memory problem were reported to Sutter about one of his own programs, that he would not prioritize fixing that, over most other work.

However, I imagine he would probably take into consideration the context. Who and what is the program for? And does the issue only reproduce if the program is misused? Does the program handle untrusted inputs? Or are there conceivable situations in which a user of the program could be duped by a bad actor into feeding the program a malicious input?

Imagine Sutter wrote a C compiler, and someone found a way to crash it. But the only way to reproduce that crash is via code that invokes undefined behavior. why would Herb prioritize fixing that over other work?

Suppose the user insists that he's running the compiler as a CGI script, allowing unauthenticated visitors to their site to compile programs, making it a security issue.

How should Herb reasonably reply to that?

withoutboats3 · a month ago

The problem in this conversation is that you are equivocating between "fixing memory safety bugs" and "preventing memory safety bugs statically." When this blog post refers to "memory safety skeptics," it refers to people who think the second is not a good way to expend engineering resources, not your imagined flagrantly irresponsible engineer who is satisfied to deliver a known nonfunctional product.

withoutboats3 commented on Io_uring, kTLS and Rust for zero syscall HTTPS server blog.habets.se/2025/04/io... · Posted by u/guntars

newpavlov · 4 months ago

This actually one of my many gripes about Rust async and why I consider it a bad addition to the language in the long term. The fundamental problem is that rust async was developed when epoll was dominant (and almost no one in the Rust circles cared about IOCP) and it has heavily influenced the async design (sometimes indirectly through other languages).

Think about it for a second. Why do we not have this problem with "synchronous" syscalls? When you call `read` you also "pass mutable borrow" of the buffer to the kernel, but it maps well into the Rust ownership/borrow model since the syscall blocks execution of the thread and there are no ways to prevent it in user code. With poll-based async model you side-step this issues since you use the same "sync" syscalls, but which are guaranteed to return without blocking.

For a completion-based IO to work properly with the ownership/borrow model we have to guarantee that the task code will not continue execution until it receives a completion event. You simply can not do it with state machines polled in user code. But the threading model fits here perfectly! If we are to replace threads with "green" threads, user Rust code will look indistinguishable from "synchronous" code. And no, the green threads model can work properly on embedded systems as demonstrated by many RTOSes.

There are several ways of how we could've done it without making the async runtime mandatory for all targets (the main reason why green threads were removed from Rust 1.0). My personal favorite is introduction of separate "async" targets.

Unfortunately, the Rust language developers made a bet on the unproved polling stackless model because of the promised efficiency and we are in the process of finding out whether the bet plays of or not.

withoutboats3 · 4 months ago

genuinely so sad to me that you are still grinding this axe. if your fantasy design works so much better - go build it then!

withoutboats3 commented on Constrained languages are easier to optimize jyn.dev/constrained-langu... · Posted by u/PaulHoule

withoutboats3 · 5 months ago

Initial comments as I write this are all negative, and also responding to something the blog post didn't claim. The only time it says faster than C is when talking about a language targeting the GPU; it is not controversial that GPUs perform better than CPUs for many workloads.

On the other hand, the results of this true fact are already seen in practice in real systems. Rust's iterator adapters, for example, allow high level "functional style" with closures to be compiled to code that is exactly the same as hand rolled C loops without unamortized bounds checks - despite guaranteeing the absence of out of bound accesses even in the face of programmer error - because the constraints of these interfaces and the design of the language enable tons of optimizations by LLVM. This has been true since Rust 1.0 more than a decade ago, it's not a promise of the future.

withoutboats3 commented on Atomics and Concurrency redixhumayun.github.io/sy... · Posted by u/LAC-Tech

dataflow · 7 months ago

It "could" for some algorithms, yes, but for a lot of algorithms, that kind of star alignment simply isn't necessary to find all the data races, was my point. And yes, TLA+ etc. can be helpful, but then you have the problem of matching them up with the code.

withoutboats3 · 7 months ago

The alternative to C++ that I meant was Rust, which statically prevents data races.

withoutboats3 commented on Atomics and Concurrency redixhumayun.github.io/sy... · Posted by u/LAC-Tech

dataflow · 7 months ago

My (limited) understanding is that the way TSAN works is better than what you're comparing it to. You don't have to rerun TSAN in a loop to finally catch a race. As long as your test has coverage of that scenario (i.e. it executes the lines of interest once within a reasonable time window) it should get caught. Of course, being dynamic, it can't catch code that you never execute during testing, but that's not such a huge problem because you can verify code coverage through other means. It's quite a bit of a different from having to make stars align by looping until some e.g. rare timing issue comes up.

The real issue here isn't that TSAN is low-confidence about absence of data races in C++. The issue is that even if it statically proved the absence of data races in the C++ sense, that still wouldn't imply that your algorithm is race-free. Because it's trivial to patch every single instance of a data race by using an atomic to get TSAN to shut up, but that in no way implies the higher-level concurrent algorithm works correctly. (e.g., if two threads perform an atomic load of some variable, then add one, then perform an atomic store back in, they would obviously stomp on each other, but TSAN wouldn't care.) It's more like a UB checker than a correctness verifier.

withoutboats3 · 7 months ago

The occurrence of data races depends on the specific non-deterministic sequence of execution of concurrent codepaths. Just because you have 100% code coverage does not mean you've covered every potential execution sequence, and its almost never practical to actually execute every possibility to ensure the absence of data races. Depending on the probability that your data race will occur, it could indeed be something you have to make stars align for TSAN to catch.

Not to talk my own book, but there is a well-known alternative to C++ that can actually guarantee the absence of data races.

withoutboats3 commented on Four Years of Jai (2024) smarimccarthy.is/posts/20... · Posted by u/xixixao

sph · 8 months ago

The faster computers get, the more the GC problem is way overblown apart from super-low-latency niches. Even AAA games these days happily run on GC languages.

There is a prominent contributor to HN whose profile says they dream of a world where all languages offer automatic memory management and I think about that a lot, as a low-level backend engineer. Unless I find myself writing an HFT bot or a kernel, I have zero need to care about memory allocation, cycles, and who owns what.

Productivity >> worrying about memory.

withoutboats3 · 8 months ago

This is exactly the attitude this blog post spends its first section pretty passionately railing against.

withoutboats3 commented on Misty: A secure distributed actor language mistysystem.com/... · Posted by u/m90

jerf · a year ago

That may be what is in the thesis, but in real Erlang, any process can list all processes on any node it can reach: https://www.erlang.org/doc/apps/erts/erlang.html#processes/0 (As the docs say, it lists "processes on the local node" but I'm fairly sure any process can RPC that to any connected node to get the local processes on that node) From there you've got a lot of introspection on the processes in question.

And beyond that, there is no sandboxing in Erlang that allows you to do anything like spawn a process that can't access the disk or network or anything like that. So in practice that doesn't even hardly buy you anything on a real system because if you were somehow running unauthenticated Erlang code you've already got access corresponding to the OS permissions of the running Erlang process. (Though for those not familiar with Erlang, "somehow running unauthenticated Erlang code" is very unlikely, to the point that it's not a realistic threat. I'm just speaking hypothetically here.)

The thesis may cover how such systems could be turned to a more secure context but it does not correspond to current Erlang.

withoutboats3 · a year ago

The IO aspect is not a surprising flaw but it's disappointing to learn that Erlang lets any process enumerate all the other ones.

withoutboats3 commented on Misty: A secure distributed actor language mistysystem.com/... · Posted by u/m90

davexunit · a year ago

Erlang actors are not privately addressable, so they cannot be used for capability security. The actors described here are.

withoutboats3 · a year ago

Joe Armstrong goes to lengths to describe the benefits of "privately addressable" actors in his thesis (though he uses different terminology). As far as I'm aware, Erlang actors are also privately addressable. cf:

> System security is intimately connected with the idea of knowing the name of a process. If we do not know the name of a process we cannot interact with it in any way, thus the system is secure. Once the names of processes become widely know the system becomes less secure. We call the process of revealing names to other processes in a controlled manner the name distribution problem— the key to security lies in the name distribution problem. When we reveal a Pid to another process we will say that we have published the name of the process. If a name is never published there are no security problems.

> Thus knowing the name of a process is the key element of security. Since names are unforgeable the system is secure only if we can limit the knowledge of the names of the processes to trusted processes.

https://erlang.org/download/armstrong_thesis_2003.pdf (page 24-25)

withoutboats3 commented on Zig's comptime is bonkers good scottredig.com/blog/bonke... · Posted by u/todsacerdoti

noelwelsh · a year ago

It would be nice to have a more indepth discussion of the issues that have been found with compile-time programming, rather than uncritical acclaim. Staged programming is not new, and people have run into many issues and design tradeoffs in that time. (E.g. the same stuff has been done in Lisps for decades, though most Lisps don't have a type system, which makes things a bit more complicated.)

Some of the issues that come to mind:

* Implementing generics in this way breaks parametricity. Simply put, parametricity means being able to reason about functions just from their type signature. You can't do this when the function can do arbitrary computation based on the concrete type a generic type is instantiated with.

* It's not clear to me how Zig handles recursive generic types. Generally, type systems are lazy to allow recursion. So I can write something like

type Example = Something[Example]

(Yes, this is useful.)

* Type checking and compile-time computation can interact in interesting ways. Does type checking take place before compile-time code runs, after it runs, or can they be interleaved? Different choices give different trade-offs. It's not clear to me what Zig does and hence what tradeoffs it makes.

* The article suggests that compile-time code can generate code (not just values) but doesn't discuss hygiene.

There is a good discussion of some issues here: https://typesanitizer.com/blog/zig-generics.html

withoutboats3 · a year ago

100%. So tiring that the discourse around this is based on 15 minute demos and not actual understandings of the trade offs. Varun Gandhi's post that you link to is great.

Based on my experience with Rust, a lot of what people want to do with its "constant generics" probably would be easier to do with a feature like comptime. Letting you do math on constant generics while maintaining parametricity is hard to implement, and when all you really want is "a trait for a hash function with an output size of N," probably giving up parametricity for that purpose and generating the trait from N as an earlier codegen step is fine for you, but Rust's macros are too flexible and annoying for doing it that way. But as soon as you replace parametric polymorphism with a naive code generation feature, you're in for a world of hurt.

withoutboats3 commented on Traits are a local maximum thunderseethe.dev/posts/t... · Posted by u/emschwartz

Ygg2 · a year ago

The problem is people want to write glue code that adds foreign traits to types they don't own.

For example they need to implement diesel trait on a type from crate they don't own (e.g. matrix)

Is it possible to square that circle? Perhaps not through traits, but something else?

withoutboats3 · a year ago

Better newtypes are the answer.

Consider Java for example. In Java, interfaces are even more restrictive than traits: only the package which defines the class can implement them for that class, not even the package which defines the interface. But this is fine, because if you want to implement an interface for a foreign class, you create a new class which inherits from it, and it can be used like an instance of the foreign class except it also implements this interface.

In Rust, to the extent this is possible with the new type pattern it’s a lot of cruft. Making this more ergonomic would ease the burden of the orphan rule without giving up on the benefits the orphan rule provides.