<br><div class="gmail_quote">On Mon, Feb 4, 2013 at 4:51 PM, Alec Flett <span dir="ltr">&lt;<a href="mailto:alecflett@chromium.org" target="_blank">alecflett@chromium.org</a>&gt;</span> wrote:<br><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></blockquote><div><br></div><div>If you are suggesting to change IndexedDB to use Vector&lt;char&gt; in order to accommodate the LevelDB interfaces, then I would suggest you not do that. Vector&lt;uint8_t&gt; is more clear than Vector&lt;char&gt; (or Vector&lt;unsigned char&gt;) at expressing the intended usage (binary versus character data). </div>

</div>