socket() always fails on WSL1 due to unsupported SOCK_CLOEXEC flag about socket2

[nu774]

the caller is responsible for handling errors.

Are you kidding? Because socket2 always forcibly adds SOCK_CLOSEXEC on Linux, the calling app has no way to retry without it.

Also what is WSL1?

https://learn.microsoft.com/en-us/windows/wsl/about

[Thomasdezeeuw]

I don't think it it s a very good design to silently add a flag that the caller even didn't passed, then miserably fails because of that.

All file descriptor types in the standard library set the SOCK_CLOEXEC flag, it's expected of types outside of it as well.

If this library has to set SOCK_CLOEXEC flag, why don't you try socket(2) call again without it when it failed?

No, socket2 is a small wrapper around system calls, the caller is responsible for handling errors.

Also what is WSL1? I'm not even sure we support that platform. It would be nice if you explain what abbreviations are before using them.

Finally, have you tried Socket::new_raw? It's very clear from the Socket::new documentation what flags are set and it recommends Socket::new_raw in cases where those flags don't make sense.

[Thomasdezeeuw]

Are you kidding? Because socket2 always forcibly adds SOCK_CLOSEXEC on Linux, the calling app has no way to retry without it.

Did you read my comment? Socket::new_raw.

Also what is WSL1?

https://learn.microsoft.com/en-us/windows/wsl/about

We support Windows, why not use that? If WSL1 doesn't support SOCK_CLOSEXEC, something quite crucial to Unix, it's not Linux.

[the8472]

Setting CLOEXEC on file descriptors is standard for pretty much every single feature that opens a file descriptor.
The socket manpage does not even list a compatibility note when SOCK_CLOEXEC was introduced, so it must have been there for a very long time.

If WSL1 does not support it then that is on WSL. Its spotty syscall-compatibility is a known issue and the reason why microsoft abandoned this approach and built WSL2 instead.
You could perhaps file a bug on the WSL issue tracker.

Are you even sure that it's because of that socket option? That seems to be fairly surprising to me because we also use it in the standard library. Can you provide an strace output (assuming that works on WSL1)?

[nu774]

Did you read my comment? Socket::new_raw.

Oh, I missed that part. Sorry.

Are you even sure that it's because of that socket option?

I found socket(2) was failing with -1 by exactly running via strace at my office.
A call to socket() shouldn't usually fail, and only suspicious thing I found was a SOCK_CLOEXEC flag.
However, now at home, I cannot reproduce it now by a simple C program (on a different PC).
I should look into this more, but anyway I'm closing this for now.
Sorry to have disturbed you.