std.posix: added missing posix error ENXIO

[chrboesch]

Per POSIX, ENXIO (“No such device or address”) may occur with read(), write(), open()/openat(), send(), and sendto() (e.g., device removed or request outside device capabilities).
read() and sendto() (and some dependencies) were missing this mapping; this PR adds it.

fixes #23383

[squeek502]

There's a decent amount of precedence for using error.NoDevice for this:

zig/lib/std/posix.zig

Line 1316 in 62e3d46

.NXIO => return error.NoDevice,

zig/lib/std/fs/Dir.zig

Line 1617 in 62e3d46

.NODEV => return error.NoDevice,

zig/lib/std/os/windows.zig

Line 135 in 62e3d46

.PIPE_NOT_AVAILABLE => return error.NoDevice,

zig/lib/std/posix.zig

Line 1877 in 62e3d46

.NXIO => return error.NoDevice,

etc

[chrboesch]

There's a decent amount of precedence for using error.NoDevice for this

But the error doesn't just mean "no device," it also means "address not found." So omitting that would be misleading. And as I already wrote to Alex, this is defined in POSIX.

This leads to the question, should we adapt the others as well?

[squeek502]

I don't have strong opinion on the naming, but, whatever name is chosen, it should be consistent. Note also that the Zig error name is used for more than just POSIX errors (and also more than just POSIX ENXIO at that), so in theory the name should also be relevant to all errors that get mapped to it (Windows errors, etc.).

The path of least resistance is probably sticking with error.NoDevice for now and opening a new issue/PR for changing the name across the board.

[andrewrk]

Please wait to make conflicts with my active branch easier

[chrboesch]

so in theory the name should also be relevant to all errors that get mapped to it (Windows errors, etc.).

That doesn't make sense to me, because then we could just write "an error occurred" without any indication of where to look for it. And for precisely this reason (at least, that's how I see it, correct me if I'm wrong), you can create meaningful errors in Zig. And if the error message says "no device" but the address isn't actually found, that means the developer (or user) has to do an extra search.

And to address your example:

.NO_MEDIA_IN_DEVICE => return error.NoDevice,
.PIPE_NOT_AVAILABLE => return error.NoDevice, 

I find the error naming very unfortunate. "No media in device" and "pipe unavailable" are two completely different things. Incidentally, this is also the reason why Windows has very explicit error messages in its API. As a developer/user, however, you only see "no device" and can then figure out whether the device is defective, not connected, or simply no CD (or whatever) is inserted. We should break this down and not make it harder for everyone to clearly identify an error.

Therefore, you should carefully consider where consolidating error messages makes sense and where it doesn't. In this case, however, I think it would be helpful to name the error as it is now, since it's a new addition for an error that hasn't been specifically caught yet.