On Mon, Feb 4, 2013 at 3:51 PM, Alec Flett <span dir="ltr"><<a href="mailto:alecflett@chromium.org" target="_blank">alecflett@chromium.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>At the moment, SerializedScriptValue uses Vector<uint8_t> (aka Vector<unsigned char>) for both it's API (createFromWireBytes, toWireBytes) as well as its internal representation. (for both v8 and jsc implementations)</div>
<div><br></div><div>The two largest consumers of this aspect of SerializedScriptValue seems to be IndexedDB and postMessage(). </div><div><br></div><div>I'm jumping through some small hoops (i.e. reinterpret_cast and whatnot) in IndexedDB to convert between Vector<uint8_t> and Vector<char> and a 'const char*' buffer in order to write out to LevelDB, who likes 'char' as opposed to unsigned char. </div>
<div><br></div><div>postMessage() seems to be pretty agnostic to char vs unsigned char, since it uses SerializedScriptValue to both produce and consume the buffers it sends between windows.</div><div><br>
</div><div>Before I did a code cleanup and just fixed up all the implementations to use Vector<char> I wanted to see if anyone had any objections here, on both the V8 and the JSC sides. The ultimate compiled code is going to be identical, but I'll be able to avoid all sorts of reinterpret_cast's at various points in the code.</div>
<div><br></div><div>objections?</div></div></blockquote><div><br></div><div>WTF/WebCore 8bits characters (LChar) are unsigned char.</div><div>Wouldn't you just push the reinterpret_cast<> to the other side of the IndexedDB module? I find it a little odd to modify WebCore based on one particular dependency (LevelDB) but maybe there is a good reason.</div>
<div><br></div><div>Benjamin</div></div>