Bug 99709

Summary: Implement ArgumentCoders for uintptr_t.
Product: WebKit Reporter: Zeno Albisser <zeno>
Component: New BugsAssignee: Zeno Albisser <zeno>
Status: RESOLVED INVALID    
Severity: Normal CC: andersca
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 98147    
Attachments:
Description Flags
Patch. andersca: review-

Zeno Albisser
Reported 2012-10-18 05:28:25 PDT
Implement ArgumentCoders for uintptr_t.
Attachments
Patch. (3.45 KB, patch)
2012-10-18 05:42 PDT, Zeno Albisser 		andersca: review-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Zeno Albisser
Comment 1 2012-10-18 05:42:39 PDT
Created attachment 169397 [details] Patch.
Zeno Albisser
Comment 2 2012-10-18 05:47:49 PDT
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.
Anders Carlsson
Comment 3 2012-10-18 11:43:38 PDT
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.
Zeno Albisser
Comment 4 2012-10-18 13:29:09 PDT
(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?
Anders Carlsson
Comment 5 2012-10-18 13:59:02 PDT
(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.
Zeno Albisser
Comment 6 2012-10-18 14:01:28 PDT
(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. :-)
Note You need to log in before you can comment on or make changes to this bug.