On Sun, Feb 10, 2013 at 11:38 AM, Darin Adler wrote:
> Short answer, yes.
>
> On Feb 10, 2013, at 9:14 AM, Glenn Adams wrote:
>
> > Because LChar is often (always?) UTF-8 encoded, the individual encoding
> units of which are 0x00 through 0xFF.
>
> Close.
>
> LChar is always Latin-1 encoded. That
Short answer, yes.
On Feb 10, 2013, at 9:14 AM, Glenn Adams wrote:
> Because LChar is often (always?) UTF-8 encoded, the individual encoding units
> of which are 0x00 through 0xFF.
Close.
LChar is always Latin-1 encoded. That’s what the "L" is for. That’s the same
thing as the first 256 code
On Sun, Feb 10, 2013 at 10:03 AM, Balazs Kelemen wrote:
> On 02/07/2013 01:48 AM, 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 typ
On 02/07/2013 01:48 AM, 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 signedness of char i
4 matches
Mail list logo
