On Feb 7, 2013, at 8:31 AM, Glenn Adams wrote:
> Given Maciej and Adam's comments, you had best stay with unsigned char/uint_8
> and convert any non-conforming usage to this pattern when needed.
Yes, I think that’s the right direction for WebKit.
-- Darin
__
On Wed, Feb 6, 2013 at 5:35 PM, Alec Flett wrote:
>
> Personally outside of WebKit I tend to see more "char*" as the common
> denominator for raw bytes.
>
I've been coding in C since around 1972, and I admit that in the early
days, char was used as a synonym for byte, however, that convention ha
On Feb 6, 2013, at 4:59 PM, Alec Flett wrote:
> On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak wrote:
>
> I think we should continue to use uint8_t instead of char as the primary way
> to represent a raw byte in WebKit. First, it's good to distinguish raw data
> from C strings at the type
On Wed, Feb 6, 2013 at 4:59 PM, Alec Flett wrote:
> On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak wrote:
>
>> I think we should continue to use uint8_t instead of char as the primary
>> way to represent a raw byte in WebKit. First, it's good to distinguish raw
>> data from C strings at the t
On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak wrote:
>
> I think we should continue to use uint8_t instead of char as the primary
> way to represent a raw byte in WebKit. First, it's good to distinguish raw
> data from C strings at the type system level, and second, the unpredictable
> signed
I think we should continue to use uint8_t instead of char as the primary way to
represent a raw byte in WebKit. First, it's good to distinguish raw data from C
strings at the type system level, and second, the unpredictable signedness of
char is actively bad for byte-oriented processing. Anothe
ok, so something else has come up: SharedBuffer. SharedBuffer has an
adoptVector method that allows you to adopt Vector... 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
to Vector to allow me to call Sha
On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett 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 (
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
th
On Mon, Feb 4, 2013 at 4:51 PM, Alec Flett wrote:
> At the moment, SerializedScriptValue uses Vector (aka
> Vector) for both it's API (createFromWireBytes, toWireBytes)
> as well as its internal representation. (for both v8 and jsc
> implementations)
>
> The two largest consumers of this aspect o
On Mon, Feb 4, 2013 at 3:51 PM, Alec Flett wrote:
> At the moment, SerializedScriptValue uses Vector (aka
> Vector) for both it's API (createFromWireBytes, toWireBytes)
> as well as its internal representation. (for both v8 and jsc
> implementations)
>
> The two largest consumers of this aspect o
At the moment, SerializedScriptValue uses Vector (aka
Vector) for both it's API (createFromWireBytes, toWireBytes)
as well as its internal representation. (for both v8 and jsc
implementations)
The two largest consumers of this aspect of SerializedScriptValue seems to
be IndexedDB and postMessage()
12 matches
Mail list logo