[webkit-dev] platform-specific differences in test case inputs

Oliver Hunt oliver at apple.com
Tue Sep 18 12:46:09 PDT 2012


What exactly are you trying to test here?  The internal serialisation format isn't exposed anywhere (nor should it be).

By definition newer formats won't be backwards compatible, or are you trying to ensure that newer deserialisers will be able to continue to deserialise old content?

--Oliver


On Sep 18, 2012, at 12:19 PM, Alec Flett <alecflett at chromium.org> wrote:

> Background: some of the storage systems use SerializedScriptValue to persist structured-clonable objects (http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data) - most of this is implemented in a V8 or JSC-specific implementation of SerializedScriptValue.
> 
> I'm adding tests for the actual values stored with SerializedScriptValue so that we can move forward with serialization changes without breaking backwards compatibility.
> 
> So many of my js tests boil down to:
> 
> testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x0000]);
> 
> Which makes sure that these two representations are equivalent by going in both directions.
> 
> The issue I'm hitting is that JSC has a different implementation with a different storage format, and the serialization/deserialization between the two storage formats is not compatible - the above code works great on V8 but JSC uses different bytes. 
> 
> I can't address this with just expectations files (i.e. only check that {} serializes to some byte array, and have different expectations depending on the port) because I need to check that specific inputs (such as old V8-based formats) can also deserialize back into the right native objects.
> 
> What I kind of want is something like:
> 
> #ifdef JSC
> <script src="serialized_script_tests_jsc.js"> </script>
> #endif
> 
> #ifdef V8
> <script src="serialized_script_tests_v8.js"> </script>
> #endif
> 
> Thoughts?
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120918/5b31ed7b/attachment.html>


More information about the webkit-dev mailing list