Simplify the code returning uint32_t to JS via IDL any in the WebGLContext a bit

RESOLVED FIXED in mozilla15

Status

()

Core
Canvas: WebGL
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

unspecified
mozilla15
x86
Mac OS X
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

I'd missed that JS::NumberValue has a uint32_t overload that will automagically do the right thing in terms of picking double vs int.  We should use it here.
Created attachment 626294 [details] [diff] [review]
Use JS::NumberValue, not JS::DoubleValue, for returning uint32_t values to JS.
Attachment #626294 - Flags: review?(bjacob)
Whiteboard: [need review]
Comment on attachment 626294 [details] [diff] [review]
Use JS::NumberValue, not JS::DoubleValue, for returning uint32_t values to JS.

Review of attachment 626294 [details] [diff] [review]:
-----------------------------------------------------------------

Isn't it unfortunate that you have to cast to uint32_t before passing to JS::NumberValue?

If the type of the argument really matters, I would templatize JS::NumberValue in the type of its argument, so that JS::NumberValue(x) would find its type by template-argument-deduction and could then automatically do the right thing.
Attachment #626294 - Flags: review?(bjacob) → review+
JS::NumberValue is overloaded for various integer types.  For the ones that fit in a JS int, it just uses an int value; for uint32_t it has to decide whether to do an int value or a double value.

I'm not sure how using a template instead of just function overloads would help here...  And in particular, the desired behavior for passing in a uint32_t and an int32_t is different.
https://hg.mozilla.org/integration/mozilla-inbound/rev/a4240610972e
Flags: in-testsuite-
Whiteboard: [need review]
Target Milestone: --- → mozilla15

Comment 5

5 years ago
https://hg.mozilla.org/mozilla-central/rev/a4240610972e
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.