On Mon, Feb 4, 2013 at 3:51 PM, Alec Flett <span dir="ltr">&lt;<a href="mailto:alecflett@chromium.org" target="_blank">alecflett@chromium.org</a>&gt;</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&lt;uint8_t&gt; (aka Vector&lt;unsigned char&gt;) for both it&#39;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&#39;m jumping through some small hoops (i.e. reinterpret_cast and whatnot) in IndexedDB to convert between Vector&lt;uint8_t&gt; and Vector&lt;char&gt; and a &#39;const char*&#39; buffer in order to write out to LevelDB, who likes &#39;char&#39; 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&lt;char&gt; 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&#39;ll be able to avoid all sorts of reinterpret_cast&#39;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&#39;t you just push the reinterpret_cast&lt;&gt; 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>