On Sun, Feb 24, 2019 at 9:55 AM Adrien Destugues <pulkoma...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
