alright should be good to go now
Should the same happen to .success or do we leave it as is?
okay so then .invalid_parameter cascades into else and the branch is commented out, explaining why it is considered unreachable/unexpected.
Personally, I think unreachable is better suited for situations where your code can guarantee an invariant internally. In this case, and for (std.posix), the invariant depends on an external...
in !30877 (commit 72f1996084) I also handled invalid_parameter with unreachable, but later removed it, since I wasn't sure if the...
alright, added the changes. Would it also make sense to create narrower errors for invalid_parameter, since most cases (if not all, currently) are unreachable?
@intCast
Fair enough, and I do agree, just wanted offered my reason for implementing it that way
I used EDK II as reference when implementing and just rolled with their api:
string.h and strings.h' (#30872) from GasInfinity/zig:libc-string(s) into master