[Zambyte]

Quotes are cute, and I prefer them over uncited negative claims. Can you link somewhere he actually said that? Because from a quick search I find him saying:

> It should be handled on a case-by-case basis. For some syscalls, EINVAL should be unreachable because it can only mean something like an invalid pointer address being passed to the kernel, or invalid flags.

> However, as you pointed out, some kernel APIs unfortunately have decided to dual-purpose this error code to mean other things, in which case we must to handle the ambiguity by mapping it to an error code. We had to make this change with EBADF recently for some syscalls, for example.

> I do want to keep the error sets clean, however, so I am opposed to a blanket modification of all EINVAL code sites without cause.

Source: https://github.com/ziglang/zig/issues/6925#issuecomment-7214...

[Zambyte]

> We discussed this in the meeting today and decided that we'll start by changing all => unreachable to => return error.Unexpected in std.posix and std.os.

https://github.com/ziglang/zig/issues/6389#issuecomment-2895...