[Webkit-unassigned] [Bug 136981] ArgumentEncoder::encode does not support long long

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Sep 22 10:31:59 PDT 2014


https://bugs.webkit.org/show_bug.cgi?id=136981





--- Comment #11 from Ting-Wei Lan <lantw44 at gmail.com>  2014-09-22 10:31:59 PST ---
(In reply to comment #10)
> (From update of attachment 238475 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=238475&action=review
> 
> > Source/WebKit2/Platform/IPC/ArgumentCoders.h:110
> > +        encoder << static_cast<int64_t>(duration.count());
> 
> What guarantees that int64_t is big enough for Rep? Or that Rep is not a double?
I don't know whether int64_t is big enough, but I can make sure Rep is an integer.
The standard says: typedef duration<signed integer type of at least 45 bits, milli> milliseconds;

Do we really needs a type which is larger than int64_t to represent time? int64_t is already very large.

> 
> I think that we need either a more specific coder, or a compile time assertion.
> 
> > Source/WebKit2/Platform/IPC/ArgumentCoders.h:118
> > -        result = std::chrono::duration<Rep, Period>(count);
> > +        result = std::chrono::duration<Rep, Period>(static_cast<Rep>(count));
> 
> Shouldn't we verify that it doesn't overflow Rep? Data sent over IPC is untrusted.
If we can solve the encoder problem, I think we can just use the same type in the decoder as in the encoder.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list