23 feb 2016, Dan Kennedy:
> On 02/23/2016 07:36 PM, E.Pasma wrote:
>> 22 feb 2016, Dan Kennedy:
>>
>>> On 02/23/2016 01:33 AM, E.Pasma wrote:
>>>>
>>>> I reproduced the memory leak and added a test in the sql script.
>>>> An alternative fix, instead of adding the missing break, is:
>>>>
>>>> case SQLITE_TEXT:
>>>> case SQLITE_BLOB:
>>>> pval->n=sqlite3_value_bytes(arg);
>>>> if (!pval->n) {
>>>> pval->z="";
>>>> } else {
>>>> pval->z=sqlite3_malloc(pval->n);
>>>> assert (pval->z); /* TODO: SQLITE_NOMEM*/
>>>> memcpy(pval->z,sqlite3_value_blob(arg),pval->n);
>>>> }
>>>> break;
>>>>
>>>> Thus sqlite3_value_blob is used to get both text or blob value
>>>> (like in sqlite3.c at line ~93615 in routine attachFunc).
>>>>
>>>> If no response I opt for the alternative fix and place it at
>>>> http://h1972688.stratoserver.net/sqlite_mprint/160223
>>>
>>>
>>> Suggest testing with text values and a utf-16 database.
>>>
>>> Dan.
>>
>> Thanks, testing with a utf-16 database does not yield any
>> differences. I inserted some 2-byte character and checked that it
>> comes out unchanged from mprint. Hope this will do.
>
> Very good.
>
> I think it's working because the call to sqlite3_value_bytes() is
> transforming the utf-16 text in the sqlite3_value to utf-8. And then
> value_blob() just returns whatever encoding the sqlite3_value has
> stored - turns out that's utf-8 by the time it's called.
>
> Dan.
And the original "type" (utf-16) is restored when the value is used
via sqlite3_result_text.
When returning text via sqlite3_result_blob:
- In a utf-8 database it can still be casted as the original text
- in a utf-16 database this is no longer true, a != cast (mprint(a) as
text)
Thanks and sorry for diverting from the subject,
