On 2016/02/13 6:52 AM, J Decker wrote:
> On Fri, Feb 12, 2016 at 8:00 PM, Igor Tandetnik wrote:
>> On 2/12/2016 10:44 PM, J Decker wrote:
>>>
>>> I expect it to take any string
>>
>> What is the basis of this expectation, other than wishful thinking?
> I don't think expectation and wishful
On Fri, Feb 12, 2016 at 8:05 PM, Warren Young wrote:
> On Feb 12, 2016, at 4:42 PM, Scott Robison
> wrote:
> >
> > I find it kind of interesting that Microsoft takes a lot
> > of (deserved) flack for not adhering to standards, yet UTF-8 came about
> > specifically because some didn't want to
On 2/12/2016 10:44 PM, J Decker wrote:
> On Fri, Feb 12, 2016 at 7:37 PM, Igor Tandetnik wrote:
>> It performs the conversion it is documented to perform. It indeed doesn't
>> perform the conversion that you, for reasons unclear, expect it to perform.
>> In other words, you engage in wishful
On 2/12/2016 10:14 PM, J Decker wrote:
> mbstowcs( out, utf8, 5 );
mbstowcs expects the string in the codepage of the current locale -
which is never UTF-8.
> for( n = 0; n < 5; n++ )
> printf( "%04x ", out[n] ); // output is 00f0 0090 0080 0081; expect d800 dc01
Why do you expect that? It
Olivier Mascia wrote:
> Are there Windows platforms, supported by SQLite source code of course, where
> the 'W' version of the APIs are not available?
Once upon a time, SQLite supported Windows 95/98/Me.
Nowadays, the code is still there, but untested.
Regards,
Clemens
On Fri, Feb 12, 2016 at 8:00 PM, Igor Tandetnik wrote:
> On 2/12/2016 10:44 PM, J Decker wrote:
>>
>> On Fri, Feb 12, 2016 at 7:37 PM, Igor Tandetnik
>> wrote:
>>>
>>> It performs the conversion it is documented to perform. It indeed doesn't
>>> perform the conversion that you, for reasons
On Fri, Feb 12, 2016 at 8:00 PM, Igor Tandetnik wrote:
> On 2/12/2016 10:44 PM, J Decker wrote:
>>
>> On Fri, Feb 12, 2016 at 7:37 PM, Igor Tandetnik
>> wrote:
>>>
>>> It performs the conversion it is documented to perform. It indeed doesn't
>>> perform the conversion that you, for reasons
On 2/12/2016 7:24 PM, J Decker wrote:
> well mbstowc and vice versa only understand 16 bit encodings, and do
> not generate codpairsand do generate d800-dfff characters which
> are entirely illegal in utf-16 (without corresponding pair)
What character in what ANSI codepage ends up converted
On Feb 12, 2016, at 4:42 PM, Scott Robison wrote:
>
> I find it kind of interesting that Microsoft takes a lot
> of (deserved) flack for not adhering to standards, yet UTF-8 came about
> specifically because some didn't want to use UCS-2
?for good reason. UCS-2/UTF-16 isn?t compatible with C
On Fri, Feb 12, 2016 at 7:37 PM, Igor Tandetnik wrote:
> On 2/12/2016 10:14 PM, J Decker wrote:
>>
>> mbstowcs( out, utf8, 5 );
>
>
> mbstowcs expects the string in the codepage of the current locale - which is
> never UTF-8.
>
>> for( n = 0; n < 5; n++ )
>> printf( "%04x ", out[n] ); // output
On Fri, Feb 12, 2016 at 7:05 PM, Warren Young wrote:
> On Feb 12, 2016, at 4:42 PM, Scott Robison wrote:
>>
>> I find it kind of interesting that Microsoft takes a lot
>> of (deserved) flack for not adhering to standards, yet UTF-8 came about
>> specifically because some didn't want to use UCS-2
On Fri, Feb 12, 2016 at 5:32 PM, Igor Tandetnik wrote:
> On 2/12/2016 7:24 PM, J Decker wrote:
>>
> What character in what ANSI codepage ends up converted by mbstowcs to an
> unpaired surrogate?
>
> What character in what ANSI codepage requires a surrogate pair to represent
> (that is,
Dear,
I see the source code for SQLite3 takes great care to support either the A
(MBCS, but not UTF8) or the W (Windows 'UTF16') versions of key APIs it depends
on that platform.
Are there Windows platforms, supported by SQLite source code of course, where
the 'W' version of the APIs are not
On Fri, Feb 12, 2016 at 4:05 PM, J Decker wrote:
> windows W is wide-char not utf-16.
> as much as A is ansi and isn't utf-8
>
Has Windows ever supported a wide character set that was not UCS-2 or
UTF-16? I've always understood Microsoft embraced UCS-2 specifically so
that it would not have to
well mbstowc and vice versa only understand 16 bit encodings, and do
not generate codpairsand do generate d800-dfff characters which
are entirely illegal in utf-16 (without corresponding pair)
But; fortunately, they do end up supporting utf-8 since it's just a
stream of bytes with a nul
windows W is wide-char not utf-16.
as much as A is ansi and isn't utf-8
On Fri, Feb 12, 2016 at 1:07 PM, Warren Young wrote:
> On Feb 12, 2016, at 1:49 PM, Clemens Ladisch wrote:
>>
>> Olivier Mascia wrote:
>>> Are there Windows platforms, supported by SQLite source code of course,
>>> where
On Feb 12, 2016, at 1:49 PM, Clemens Ladisch wrote:
>
> Olivier Mascia wrote:
>> Are there Windows platforms, supported by SQLite source code of course,
>> where the 'W' version of the APIs are not available?
>
> Once upon a time, SQLite supported Windows 95/98/Me.
The DOS-based versions of
17 matches
Mail list logo
