>The two sockets are indistinguishable.
What? This smells of a terrible workaround for some POSIX behavior that was explicitly standardized as not thread safe or something. Since Linux is required to be built with -fno-strict-aliasing, trivial sharing of sv wouldn't cause any new problems.

>>108196251
>i guess it's like pipe, but with sockets?
Yeah basically. The idea, like with pipe, is that you call this in the parent, let the child inherit one of the fds, and the parent keeps the other.

>except both ends are read/write
Not only that, you can pass file descriptors over them

>>108196294
I think it just means that there isn't a distinct sender and receiver like with pipe

>>108196313
i will say, the pipe-then-fork flow is pretty convenient and generally "just werks", so i can definitely see the appeal of having the same thing with sockets

>>108196251
I respect your hard work and commitment to the cause, anon

>>108196389
thanks! i am honestly a bit surprised i've managed to keep it up every day so far, but i'm glad that i have. it's a bit difficult when i'm busy doing things (or easy to forget about, at least), but so far so good!

>>108189613
>to ensure that it's actually an address and not a raw pointer
wdym by this? a pointer is only valid when holding an address or being null... is that what you mean? nonnull?

>>108196821
by address i mean a pointer to a value on the stack, and yes it has guarantees of being non-null because you're taking its address with the & operator

>>108196251
is this
>adhoctism?

>>108189613
>i haven't bothered with restrict, because it seems like that would start to get too wordy
restrict is pretty hard to use safely from what I've heard. Easy to accidentally introduce UB, and the compiler won't warn you if you screw it up