The default bug view has changed. See this FAQ.

Fix inclusion of jsobj.h in Content code due to ArrayBuffer optimizations

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: nsm, Assigned: nsm)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: 

Since ArrayBuffer was collapsed into a JSObject by bug 656519, content and DOM code which used it required the inclusion of jsobj.h, which is frowned upon :)

This patch creates two versions of the public API for ArrayBuffer, JS_GetArrayBufferByteLength and JS_GetArrayBufferData which are not-inline and can be used treating JSObject as opaque, while js_GetArrayBufferByteLength and js_GetArrayBufferData are used by the engine.

Reproducible: Always
Depends on: 656519
Created attachment 539672 [details] [diff] [review]
API fix
Comment on attachment 539672 [details] [diff] [review]
API fix

My only thought is that you could let the inlined versions still be member functions on ArrayBuffer (and let them simply be undefined for consumers outside the engine) and simply defined in jstypedarrayinlines.h. Do you have feelings one way or the other?
Attachment #539672 - Flags: review+

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
I put them as functions for consistency. Both private and public have the same name except for js/JS.
> My only thought is that you could let the inlined versions still be member
> functions on ArrayBuffer

Fwiw, this was my assumption about how we'd do it.
Created attachment 539834 [details] [diff] [review]
API fix

Inline implementation is kept part of the class.
Attachment #539672 - Attachment is obsolete: true
Yeah, the consistency is a hold-over from the pre-C++ days of SpiderMonkey. We're migrating more and more towards class methods over js_* methods.
Assignee: general → nsm.nikhil
http://hg.mozilla.org/tracemonkey/rev/8b3dc129aed8

I didn't add the bug # to the checkin message, sadly :-/.

Updated

6 years ago
Whiteboard: fixed-in-tracemonkey
Back it out and reland with the bug#?
But it's not clear why that wasn't there to start with....
http://hg.mozilla.org/tracemonkey/rev/ca93cfe414a0 <-- backout
http://hg.mozilla.org/tracemonkey/rev/e3c7aa315ca5 <-- relanding

Nikhil, in general, when you write your commit messages for patches, please include the bug # in the commit message. It make it easier when doing hg archaeology to tie specific commits to bugs.
cdleary-bot mozilla-central merge info:
http://hg.mozilla.org/mozilla-central/rev/ca93cfe414a0 (backout)
http://hg.mozilla.org/mozilla-central/rev/e3c7aa315ca5
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.