dgl/javascript-v8 — pull request #14 by alankila (2014-10-17 12:08:36+00:00)
Title: Updates for compatibility and bug fixing

Hey,

there are a number of things that are broken in the libv8 integration. I've got a bunch of fixes with some titles. I know this commit history isn't the cleanest ever so feel free to just squash all the changes into one.

- FIrstly, the SvUOK change allows use of 32-bit unsigned values on 32-bit builds. Without this fix, large enough value gets turned into a negative 32-bit integer value when going from Perl to V8. There is no issue in 64-bit build however.

- Moving on, newSV(0) is required rather than &PL_sv_undef so that JS-returned arrays and hashes have elements that can be assigned to normally.

- Then I noticed by creating and disposing many contexts that string_wrap and make_function were leaked per created context. So, I added disposing of those to reduce memory leakage. (I've seen that Javascript::V8 also leaks the Perl functions bound to the context, but my perl-fu is not sufficient to understand why that occurs, so I haven't fixed that issue.)

- Then there is an issue with the hash key iteration because the UTF-8 flag is ignored. There may be bugs in Perl here. For instance, HeSVKEY_force() returns a SV, and SVs are supposed to have UTF-8 flag on if their char* content is in fact UTF-8. However, I think in this case for some reason this doesn't happen. So, there's some complexity in the hv2object loop to test if key is UTF-8. The old code actually replaces e.g. latin1 characters in non-utf8 strings with "\ufffe" because it passes the data in binary fashion to String::new(). hv_iternextsv() is broken in Unicode world.

- I also silenced a bunch of warnings by casting to (void) rather than using a local variable with no further usages. The (void) is documentation for "I'm ignoring the return value intentionally".

- I used uint32_t to avoid a comparison between signed and unsigned message.