On Wed, Feb 6, 2013 at 5:35 PM, Alec Flett alecfl...@chromium.org 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,
ok, so something else has come up: SharedBuffer. SharedBuffer has an
adoptVector method that allows you to adopt Vectorchar... 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 Vectoruint8_t
to Vectorchar to
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.
On Wed, Feb 6, 2013 at 4:59 PM, Alec Flett alecfl...@chromium.org wrote:
On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak m...@apple.com 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
On Feb 6, 2013, at 4:59 PM, Alec Flett alecfl...@chromium.org wrote:
On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak m...@apple.com 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
At the moment, SerializedScriptValue uses Vectoruint8_t (aka
Vectorunsigned char) 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
On Mon, Feb 4, 2013 at 3:51 PM, Alec Flett alecfl...@chromium.org wrote:
At the moment, SerializedScriptValue uses Vectoruint8_t (aka
Vectorunsigned char) for both it's API (createFromWireBytes, toWireBytes)
as well as its internal representation. (for both v8 and jsc
implementations)
The
On Mon, Feb 4, 2013 at 4:51 PM, Alec Flett alecfl...@chromium.org wrote:
At the moment, SerializedScriptValue uses Vectoruint8_t (aka
Vectorunsigned char) for both it's API (createFromWireBytes, toWireBytes)
as well as its internal representation. (for both v8 and jsc
implementations)
The
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
On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett alecfl...@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
10 matches
Mail list logo
