[webkit-dev] Encoding and decoding ProcessID

[Ryosuke Niwa]

On Sun, Feb 24, 2019 at 9:55 AM Adrien Destugues <pulkomandy at pulkomandy.tk>
wrote:

> We are finally starting to look into moving the Haiku port to WebKit2.
>
> We have hit one little problem I'm not sure how to solve. Our pid_t on
> 32bit Haiku is declared as a signed long integer (this is for legacy
> reasons and not something we can fix easily). Our uint32_t is a signed
> integer (not long). This creates a compilation error when using pid_t
> with IPC::Encoder, because none of the encode() functions match when
> trying to pass a pid_t in our case.
>
> Our options seems to be:
> - Cast pid_t to int32_t when encoding it. I fear this would break other
>   platforms if they decide to use a 64bit pid_t, for example
>

We definitely don't want to do this for the reason you stated.

- Add an encode(pid_t) to the IPC::Encoder. I fear on other platforms it
>   would complain that this is the same as encode(int32_t) and break the
>   build
>

We may want to wrap pid_t in a struct when passing around IPC.
That would work around this problem.

- Define WTF::ProcessID as int32_t instead of pid_t, which I think could
>   work, afte rfixing some compiler warnings (we will need to cast back
>   to pid_t when passing it to OS functions, I think)
>

We definitely don't want to do this for the same reason as the first.

Note that because 32-bit UI process on macOS would start 64-bit WebContent
process, it's very important that every IPC message explicitly specifies
the size of POD types. We can't, for example, use uintptr_t whose size
varies between 32-bit and 64-bit builds on macOS in our IPC code.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20190224/a9ae5cae/attachment.html>