[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