c/o http://crbug.com/151927 ../../third_party/WebKit/Source/WebCore/Modules/indexeddb/IDBCursor.cpp:174:28:error: comparison of constant 9007199254740991 with expression of type 'long' is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (count < 1 || count > maxECMAScriptInteger) { count is a long. This comparison should be against 2^32-1 not 2^53-1
Thanks for looking at this! (In reply to comment #0) > count is a long. This comparison should be against 2^32-1 not 2^53-1 Should that be 2^31-1?
Hrm.... this actually gets tricky. The WebIDL in the spec for this is: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#cursor void advance ([EnforceRange] unsigned long count); And WebIDL says: http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long "If the conversion to an IDL value is being performed due to ... being passed as an operation argument annotated with the [EnforceRange] extended attribute ... then ... if x < 0 or x > 2^32 − 1, then throw a TypeError" It would be 2^31-1 if it were a (signed) long. We actually have this marked as |long| in the WebKit IDL to avoid default handling of negative values since [EnforceRange] isn't implemented. Correct behavior of [EnforceRange] is in webkit.org/b/96798 which is blocked on a v8 bug. As it stands now, passing 2^32-1 actually fails with a TypeError as well, which is incorrect. This is because V8Binding.cpp's toInt32 conversion for out of bound values returns 0. So I should probably flip the IDL back to "unsigned long", leave only the 0 test in the code, and add 2^31-1 (ok), 2^31 (ok), 2^32-1 (ok), and 2^32 (type error) as test cases.
Created attachment 169954 [details] Patch
(In reply to comment #2) > > So I should probably flip the IDL back to "unsigned long", leave only the 0 test in the code, and add 2^31-1 (ok), 2^31 (ok), 2^32-1 (ok), and 2^32 (type error) as test cases. ... but I actually had to convert it (temporarily) to "long long" as the binding code's toUint32() conversion for "unsigned long" was not doing the right thing either. *sigh*
Comment on attachment 169954 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=169954&action=review > Source/WebCore/Modules/indexeddb/IDBCursor.cpp:173 > + const unsigned long maxUnsignedLong = 0xffffffff; Can we use ULONG_MAX or numeric_limits<unsigned long>()?
Comment on attachment 169954 [details] Patch Attachment 169954 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14499260
Created attachment 169976 [details] Patch
(In reply to comment #5) > Can we use ULONG_MAX or numeric_limits<unsigned long>()? Done (with UINT_MAX - turns out ULONG_MAX ends up being the unsigned long long max...)
Comment on attachment 169976 [details] Patch Clearing flags on attachment: 169976 Committed r132140: <http://trac.webkit.org/changeset/132140>
All reviewed patches have been landed. Closing bug.