Re: Null Characters in Strings, Version 9.3.1

(2014/02/19 5:30), Heikki Linnakangas wrote:
> On 02/18/2014 09:39 PM, Nils Gösche wrote:
>> Heikki wrote:
>>
>>> On 02/18/2014 07:06 PM, Nils Gösche wrote:
>>>> I wrote:
>>>>
>>>>> If I retrieve the value in a C# program using the ODBC driver, I get
>>>>> a string that has a null character at position 459, but a total
>>>>> length of 487!  The string up to position 458 is correct, but has
>>> now
>>>>> been extended with a null character and a few junk characters.
>>>>
>>>> Am I the only one thinking this is a serious bug?
>>>
>>> Maybe.. I don't have a C# environment to test this with; if you can
>>> write a small stand-alone C program to reproduce this and post it, I'll
>>> take a look.
>>
>> Thanks! I have never written an ODBC program in C before. Wow, what a
>> PITA... ;-).
>
> Yep, it's quite verbose :-).
>
>>  I took a little example program from Microsoft's site and adapted
>> it.  The code is attached.
>
> I'm afraid I can't easily compile and execute that either, with all the
> Windows-ism's in it. Could you pick one of the regression test cases
> (e.g
> http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob_plain;f=test/src/select-test.c;hb=HEAD),
> and modify it to reproduce the problem? And please also include the SQL
> statements to create the test table and data.
>
>>  The essential point is at line 353:
>>
>>      if (wcslen(pThisBinding->wszBuffer) * sizeof(wchar_t) !=
>> pThisBinding->indPtr)
>>      {
>>          wprintf(L"2 * wcslen = %d, indPtr = %d\n",
>> wcslen(pThisBinding->wszBuffer) * sizeof(wchar_t),
>>                  pThisBinding->indPtr);
>>      }
>>      else
>>      {
>>          wprintf(pThisBinding->fChar ? DISPLAY_FORMAT_C:DISPLAY_FORMAT,
>>                  PIPE,
>>                  pThisBinding->cDisplaySize,
>>                  pThisBinding->cDisplaySize,
>>                  pThisBinding->wszBuffer);
>>      }
>>
>> If I run this with version 9.2.1 of the driver (I am using 32 Bit
>> here), it will go to the else clause and print the value of the text
>> column. However, if I run this with the latest version, I get the
>> following output:
>
> Hmm. If you could pinpoint it to the exact commit that changed the
> behavior, that would help too.

Maybe it's caused by the commit 3666c87c1440862bde2e6b8f43ee585deed70d31
Author: Hiroshi Inoue <inoue@tpf.co.p>
Date:   Thu Aug 22 20:40:01 2013 +0900

     When LF->CR+LF conversion causes an buffer truncation, supress the
conversion (in case of unicode).

Nils, please try to turn off *LF <-> CR/LF conversion* option.
Anyway I can't think of the way to cure the problem other than putting
  back the commit.

regards,
Hiroshi Inoue