Implement ArgumentCoders for uintptr_t.
Created attachment 169397 [details] Patch.
We will need this change for implementing GraphicsSurface on Windows. The actual platform specific surface token on windows is of type HANDLE (which is a void*). We will have to transfer this value through IPC from the WebProcess to the UIProcess. Note that it is not actually dereferenced as a pointer! Because of Windows allowing 32bit and 64bit binaries being executed on the same system, we would only know at compile time if we need to allocate/transfer 32bit or 64bit per token. By making use of uintptr_t we can nicely neglect this question and make the compiler decide.
Comment on attachment 169397 [details] Patch. We don't want to have encoders/decoders for types whose size is different on different platforms. Just use uint64_t for this.
(In reply to comment #3) > (From update of attachment 169397 [details]) > We don't want to have encoders/decoders for types whose size is different on different platforms. Just use uint64_t for this. I kind of expected that. But is there an actual reason for that? Does it cause any kind of problems I have not been thinking about?
(In reply to comment #4) > (In reply to comment #3) > > (From update of attachment 169397 [details] [details]) > > We don't want to have encoders/decoders for types whose size is different on different platforms. Just use uint64_t for this. > > I kind of expected that. But is there an actual reason for that? Does it cause any kind of problems I have not been thinking about? On Mac for example, we have IPC between 32-bit and 64-bit processes for plug-ins. Allowing integer types whose size differs could easily introduce bugs so it's better to just not do it.
(In reply to comment #5) > On Mac for example, we have IPC between 32-bit and 64-bit processes for plug-ins. Allowing integer types whose size differs could easily introduce bugs so it's better to just not do it. Ok, that makes sense. Haven't been aware of that use case. Thanks for the explanation. :-)