<div dir="ltr"><div dir="ltr">Hi<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 5, 2022 at 7:52 PM Thiago Macieira <<a href="mailto:thiago@kde.org">thiago@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Friday, 5 August 2022 00:35:54 PDT Marc-André Lureau wrote:<br>
> As you probably know, HANDLEs are not FD. And Windows has the 2 types, and<br>
> functions to map to/from the 2 (_get_osfhandle/_open_osfhandle).<br>
<br>
There's no way to transport file descriptors as numbers anyway because they're <br>
local to each application. And on Windows, it's entirely controlled by the <br>
runtime (userspace), which is why those two functions exist.<br>
<br>
That means the wire format is irrelevant. I suggest keeping 'h' because <br>
there's no difference. The fact that on Windows they're marshalled as actual <br>
handles and on Linux they're out-of-band is an implementation detail.<br>
</blockquote></div><div><br></div><div>FDs are not HANDLEs, we shouldn't mix the two (a mistake commonly observed and annoying to clean up).</div><div><br></div><div>If some day Windows sockets learn SCM_RIGHT, we should transfer FDs values. <br></div><div><br></div><div>We could eventually use 'h' for FDs or HANDLEs or SOCKETs (or other kind as necessary), the "handle array" contains the type details. But then 'h' implementation will be different on Windows, regardless of potentially future same SCM_RIGHT support. I think it's a better idea to treat HANDLEs as a different type.<br></div><div><br></div><div><br></div><br>-- <br><div dir="ltr" class="gmail_signature">Marc-André Lureau<br></div></div>