[webkit-dev] SerializedScriptValue: signed vs unsigned char

[Alec Flett]

ok, so something else has come up: SharedBuffer. SharedBuffer has an
adoptVector method that allows you to adopt Vector<char>... some of the
stuff I'm using that interacts with LevelDB is also dealing with
SharedBuffer, hence I've had to do some nasty casting from Vector<uint8_t>
to Vector<char> to allow me to call SharedBuffer.adoptVector()

And again, we could tweak SharedBuffer to accept Vector<unsigned char> but
now we have two subsystems (LevelDB, and SharedBuffer) that seem to prefer
"char" as raw data.

Personally outside of WebKit I tend to see more "char*" as the common
denominator for raw bytes.

Further, there are no subsystems that actually depend on
SerializedScriptValue using uint8_t - it was just what we decided to use
when (ironically) we were hooking up IndexedDB to JSC, just a month or so
ago.

So far Benjamin objected, and then seems to have rescinded. Glenn, do you
depend on SerializedScriptValue's current method signatures?

Alec


On Mon, Feb 4, 2013 at 5:14 PM, Benjamin Poulain <benjamin at webkit.org>
 wrote:

> On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett <alecflett at chromium.org> wrote:
>
>> Well, nobody is explicitly using LChar with SerializedScriptValue (maybe
>> it should, maybe that's another issue)  but I guess this is why I'm asking
>> - I'm happy to just deal with this in IDB with some ugly reinterpret_casts
>> here and there (ok maybe not happy, but satisfied enough) if folks prefer
>> that. I don't personally find uint8_t to be any more intuitive than char,
>> but it sounds like some do. Nevermind...
>>
>
> Well, since you never use character types and only raw data, just ignore
> my comment.
>
> As far as I know, it is already common to use signed char for raw data (in
> the network stack for example).
>
> Benjamin
>


On Wed, Feb 6, 2013 at 4:06 PM, Alec Flett <alecflett at google.com> wrote:

> ok, so something else has come up: SharedBuffer. SharedBuffer has an
> adoptVector method that allows you to adopt Vector<char>... some of the
> stuff I'm using that interacts with LevelDB is also dealing with
> SharedBuffer, hence I've had to do some nasty casting from Vector<uint8_t>
> to Vector<char> to allow me to call SharedBuffer.adoptVector()
>
> And again, we could tweak SharedBuffer to accept Vector<unsigned char> but
> now we have two subsystems (LevelDB, and SharedBuffer) that seem to prefer
> "char" as raw data.
>
> Personally outside of WebKit I tend to see more "char*" as the common
> denominator for raw bytes.
>
> Further, there are no subsystems that actually depend on
> SerializedScriptValue using uint8_t - it was just what we decided to use
> when (ironically) we were hooking up IndexedDB to JSC, just a month or so
> ago.
>
> So far Benjamin objected, and then seems to have rescinded. Glenn, do you
> depend on SerializedScriptValue's current method signatures?
>
> Alec
>
>
> On Mon, Feb 4, 2013 at 5:14 PM, Benjamin Poulain <benjamin at webkit.org>wrote:
>
>> On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett <alecflett at chromium.org>wrote:
>>
>>> Well, nobody is explicitly using LChar with SerializedScriptValue (maybe
>>> it should, maybe that's another issue)  but I guess this is why I'm asking
>>> - I'm happy to just deal with this in IDB with some ugly reinterpret_casts
>>> here and there (ok maybe not happy, but satisfied enough) if folks prefer
>>> that. I don't personally find uint8_t to be any more intuitive than char,
>>> but it sounds like some do. Nevermind...
>>>
>>
>> Well, since you never use character types and only raw data, just ignore
>> my comment.
>>
>> As far as I know, it is already common to use signed char for raw data
>> (in the network stack for example).
>>
>> Benjamin
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130206/3c7b714e/attachment.html>