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 <benja...@webkit.org> wrote: > 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 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 <alecfl...@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 <benja...@webkit.org>wrote: > >> 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 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 >> > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev