Add JS_ReportErrorNumberUTF8Array
Categories
(Core :: JavaScript Engine, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox75 | --- | fixed |
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
Details
Attachments
(1 file)
I am trying to have an API where people call my function with some varargs and then I insert an arg at the beginning, or modify the first arg (the two are equivalent in my case for various reasons) and want to report an error with the resulting arglist.
But there's no way to forward varargs in C/C++ (apart from variadic templates, and in this case that would mean duplicating the "modify the first arg" code on a per-instantiation basis, which leads to a lot more code bloat than I can accept here). So I was figuring I'd just put the args in an array and hand them off, like one can do with JS_ReportErrorNumberUCArray
. But there's no API to do that in the JS engine with UTF-8 strings, as far as I can tell.
For now it looks like I will be converting all my strings from ASCII to UTF-16 and using JS_ReportErrorNumberUCArray
, but that seems a little silly in general, because then AutoMessageArgs::init
will happily go and convert them back to heap-allocated UTF-8.
Comment 1•5 years ago
|
||
We're probably at the point now -- if we were not there years ago -- where we should kill off all the varargs use in error-reporting APIs and internals. I don't quite remember if the current error internals make it easy to add the API you want; if they do we should certainly do the fast hack to address the immediate need.
But there's a definite indolence permeating error reporting, with respect to varargs, that we ought be rectifying. As to varargs, as to requiring the full computation of every parameter-string even if it turns out no error/warning is to be reported, etc.
Assignee | ||
Comment 2•5 years ago
|
||
I don't quite remember if the current error internals make it easy to add the API you want
I think they do, based on some reading earlier today. If I end up with time, I will do it, but I want to write the actual substantive patches first, and hacking around this is faster than not.
Once we have the new API, we can do some other cleanups too, like bug 1619112.
Assignee | ||
Comment 3•5 years ago
|
||
Updated•5 years ago
|
Comment 5•5 years ago
|
||
bugherder |
Description
•