Closed
Bug 553997
Opened 15 years ago
Closed 15 years ago
JS_ISSPACE now uses js_A, js_X and js_Y which are not exported
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: glandium, Unassigned)
Details
Attachments
(1 file)
1.65 KB,
patch
|
shaver
:
review-
|
Details | Diff | Splinter Review |
gxine uses JS_ISSPACE, and since 1.9.2, JS_ISSPACE uses JS_CCODE, which uses js_A, js_X and js_Y. These are not exported from the library.
Also note that while gxine doesn't use JS_ISWORD, this macro has the same problem with js_alnum, which is not exported either. While the patch I'm attaching doesn't export js_alnum, maybe it should be, too.
Reporter | ||
Updated•15 years ago
|
Attachment #433900 -
Attachment is patch: true
Attachment #433900 -
Attachment mime type: application/octet-stream → text/plain
Attachment #433900 -
Flags: review?(brendan)
Comment 1•15 years ago
|
||
gxine shouldn't be using JS_ISSPACE, it's not part of the public API. why are they including jsstr.h at all?
Reporter | ||
Comment 2•15 years ago
|
||
Short answer: because all headers from js/src are installed as system headers.
Comment 3•15 years ago
|
||
Hmm, I don't think we should export and maintain internal API because of packaging infelicities. The gxine guys should find something else to use for this functionality. Thanks for the report, though!
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Comment 4•15 years ago
|
||
Comment on attachment 433900 [details] [diff] [review]
Patch
r-: don't want to add to the export table or in general support embedding use of internal headers.
Attachment #433900 -
Flags: review?(brendan) → review-
Reporter | ||
Comment 5•15 years ago
|
||
(In reply to comment #4)
> (From update of attachment 433900 [details] [diff] [review])
> r-: don't want to add to the export table or in general support embedding use
> of internal headers.
Where is the distinction made between internal and public headers ?
Comment 6•15 years ago
|
||
Not clearly enough, which is our fault. The published header set is "js*api.h and everything they include", but embeddings shouldn't directly include any file that isn't js*api.h (that is, they shouldn't include jspubtd.h or such directly).
Reporter | ||
Comment 7•15 years ago
|
||
(In reply to comment #6)
> Not clearly enough, which is our fault. The published header set is "js*api.h
> and everything they include", but embeddings shouldn't directly include any
> file that isn't js*api.h (that is, they shouldn't include jspubtd.h or such
> directly).
Shouldn't the install rules in js/src be modified accordingly, then ? (In which case I'll file another bug)
Comment 8•15 years ago
|
||
To be blunt, I didn't know anyone used the install rules! Please do file (or, I fear, find already filed) a bug.
Reporter | ||
Comment 9•15 years ago
|
||
Before I file a new bug, could you tell me if you'd expect jsprvtd.h and jsopcode.h to be public ? That doesn't sound right, yet they are included from jsdbgapi.h and jsxdrapi.h.
Reporter | ||
Comment 10•15 years ago
|
||
Also note that the following headers contain JS_PUBLIC_API symbols, while they are not included from any *api.h file:
jsarena.h
jsbit.h
jsdhash.h
jsfile.h
jshash.h
jsprf.h
Comment 11•15 years ago
|
||
How about I answer comments 9 and 10 in your new bug? :)
Reporter | ||
Comment 12•15 years ago
|
||
Filed bug 554088
You need to log in
before you can comment on or make changes to this bug.
Description
•