On Sat Jun 3 22:38:31 2023 +0000, Zebediah Figura wrote:
For example, if a Windows program connects to a Linux program's socket
at `/tmp/server.sock`, which of the following is correct for `getpeername` to fill in?
- `/tmp/server.sock`
- `Z:\tmp\server.sock`
- `server.sock`
- [something else]
And if a Linux program with a socket bound to `/tmp/server.sock`
connects to a Windows socket at `C:\tmp\server.sock`, which is correct for `accept` to return on the Windows side?
Correct `getpeername` and `accept` functionality will take a
non-insignificant amount of effort regardless of the implementation chosen. Should those be done with separate merge requests or included here? At this point, the last question is hard to answer without understanding what the actual implementation requires, which is mainly why I'm asking for all these tests :-) That relative and absolute paths are preserved in getsockname() suggests that the original path isn't interpreted or normalized at all, which makes some degree of sense. It then however raises the question of whether the getpeername() path is interpreted or normalized, because it'd be at least a little surprising if it isn't. (For example, a relative path doesn't always make sense). Granted, I don't actually know how a real Unix behaves in this respect. We may want to just punt on getpeername() entirely [i.e. stub it out, with a FIXME, for AF_UNIX], but I think it shouldn't be too hard to at least run a couple of tests.
Windows indeed does not modify the path. `getpeername` and `getsockname` return the original path, even if it is relative or prefixed. Notably, Windows itself does not implement `accept` correctly, as it does not fill in the path but does set `sun_family` to `AF_UNIX`.
I think punting on `getpeername` with regard to Windows <-> Unix sockets is fine since there is absolutely no precedent there and Wine doesn't even have the infrastructure to test a resolving implementation, but `getpeername` correctly returning the path of Windows-created AF_UNIX sockets should be implemented, in this or a following merge request.
Given this, I reaffirm my opinion that forwarding `getpeername` to `sock_ioctl` is the cleanest way to handle this, and my next push will include an implementation of that. I can split it off into its own merge request if the changes made are deemed too extensive to be included here.