JSIdArray structure missing from jsapi.h?

[Miles]

Hi there,

I may be a bit late as the release has already been done... but I am trying to make the necessary changes (from 1.8.5) to my C code to be able to test the version 17 release in my embedding.

The JSIdArray structure seems to be missing from jsapi.h which is needed for JS_Enumerate so I cannot do the following:

JSIdArray *variables_IdArray;
variables_IdArray = JS_Enumerate(cx, variables_obj);
for (i=0; i<variables_IdArray->length; i++)
{
....
}

which I could do in 1.8.5.
I get errors such as:

./dj_main.c(1150): error: pointer to incomplete class type is not allowed
for (i=0; i<variables_IdArray->length; i++)

It seems to be defind in jsatom.h but is using the 'js' C++ namespace so I don't see how I could use it in C code (my code is C, not C++).
Is anyone aware of a workaround I can use?


Thanks

Miles Thornton

[Jeff Walden]

On 03/26/2013 09:44 AM, Miles wrote:
> The JSIdArray structure seems to be missing from jsapi.h which is needed for JS_Enumerate so I cannot do the following:
>
> JSIdArray *variables_IdArray;
> variables_IdArray = JS_Enumerate(cx, variables_obj);
> for (i=0; i<variables_IdArray->length; i++)
> {
> ....
> }
>
> which I could do in 1.8.5.
> I get errors such as:
>
> ./dj_main.c(1150): error: pointer to incomplete class type is not allowed
> for (i=0; i<variables_IdArray->length; i++)
>
> It seems to be defind in jsatom.h but is using the 'js' C++ namespace so I don't see how I could use it in C code (my code is C, not C++).
> Is anyone aware of a workaround I can use?

The HeapId you see in the code I *think* doesn't do anything -- it's just transitional as we move toward a moving GC. So for now, I think just adding this definition to some header of yours should work:

struct JSIdArray
{
int length;
jsid arr[1];
};

I think. If you encounter duplicate-symbols issues during linking, you might need to change jsatom.h to use jsid instead of HeapId when you compile the JS engine, as a mini-patch. C++ users should for now just #include jsatom.h to get the symbol. Poor hygiene on our part :-( but it can't really be helped now. We've substantially culled the installed-headers list on trunk, and added new public headers with better-defined sets of functionality in them, so these problems should be reduced in future releases.

A more general concern for you, moving foward. SpiderMonkey is switching from a C API to a C++ API. On trunk, jsapi.h is a C++ header. This has been in the cards for a fairly long time, and I believe we've mentioned it before here and elsewhere, repeatedly. It is very nearly a requirement to implement a moving GC -- it's simply too hard to have correct read/write barrier usage for access to GC-managed values and such without C++ language features (operator overloading, RAII, and others). For 17 you may still be able to hack around differences, but come 24 you'll need to use C++. (Note that other JS engines out there have C++ APIs already, often for reasons that include these moving-GC concerns.)

Jeff

[Robin Ehrlich]

On 03/26/2013 09:44 AM, Miles wrote:
> The JSIdArray structure seems to be missing from jsapi.h which is needed
> for JS_Enumerate so I cannot do the following:
>
> JSIdArray *variables_IdArray;
> variables_IdArray = JS_Enumerate(cx, variables_obj);
> for (i=0; i<variables_IdArray->length; i++)
> {
> ....
> }
>

I used the following in the latest release:

uIds = JS_Enumerate(cx, uObj1);
uIdsLen = JS_IdArrayLength(cx, uIds);
for (i = 0; i < uIdsLen; i++) {
JS_IdToValue(cx, JS_IdArrayGet(cx, uIds, i), &v);