FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2014-04-09 6:40 GMT+01:00 LacaK <lacak AT zoznam.sk>:
> Frediano Ziglio  wrote / napísal(a):
>
>> 2014-04-08 11:08 GMT+01:00 LacaK <lacak AT zoznam.sk>:
>>
>>>
>>> Hi,
>>> when I look into tds_types.h (which is build on misc/types.csv) there is
>>> function tds_get_size_by_type() used f.e. by dbconvert()
>>> And for SYBMSDATE it returns 4 (IMO it is wrong set size=4 in types.csv)
>>> Is it correct ?
>>> (as far as I understand it should be size if struct which holds this data
>>> type i.e.:
>>> there should be:
>>>  case SYMBSDATE:
>>>  case SYMBSTIME:
>>>  case SYMBSDATETIME2:
>>>  case SYMBSDATETIMEOFFSET:
>>>     return sizeof(TDS_DATETIMEALL);
>>>
>>> ?
>>> When I change it this way, it works as expected for me.
>>> Thanks
>>> -Laco.
>>>
>>>
>>
>>
>>
>> Well... could be... this function is used in a lot of places. As the
>> fixed column is 0 I don't think should break anything.
>>
>> What did go wrong before you changed the code?
>>
>
> Look please in src/dblib/dblib.c at dbconvert() function.
> There is call to tds_get_size_by_type(desttype) used in case when "srctype
> == desttype"
> And then return value (i.e. size) is used in: memcpy(dest, src, ret);
> When size is wrong memcpy does not copy all data.
> When tds_get_size_by_type() does not known "desttype" then -1 is returned,
> which in my environment causes freezing application.

Well, there is a large switch that prevent the call of
tds_get_size_by_type for new MS date/time types so you have probably
change this switch and now the code does not work for you. Is it
right?

> (may be that memcpy expect as 3rd argument "unsigned size", so supplying -1
> causes copy of large memory block)
> (f.e. for desttype=SYBMSDATETIME2 there is in types.csv: size=-1, which
> causes that this type is omited when generating tds_types.h from types.pl
> ... )
>
> As another example please look at SYBDATETIME, there is size=4 which
> correspondes to sizeof(TDS_DATETIME) and also sizeof(DBDATETIME) used by
> sybdb.h ... this is IMO correct ...
>
> Sizeof(TDS_DATETIMEALL) = 24 so setting this size for MSDATE, MSTIME,
> MSDATETIME2, MSDATETIMEOFFSET should ge solution?
>

24 ?? On my 64 bit machine is 16 and should be 16. However you can use
directly sizeof(TDS_DATETIMEALL) in csv file.

Well, questions that raise on my mind are due to the use of this
function and what does it mean the "size" of tds_get_size_by_type.
I'll explain. Is size the size of the network bytes we receive from
the server or is the size of the structure stored by libTDS for this
type? Actually the table reply with the first (network bytes) but you
are changing with the last (structure bytes). The problem is really
this, the function is used for both purposes :(

For this reason I think I found a bug in libTDS. If you return a
VARIANT type from the conversion of these new types I don't know what
can happen (see src/tds/data.c).

Yesterday I replaced the size in the csv files and do a check. With
tds 7.3 I had a lot of problems with some internal checks. Well...
actually removing the test seems to not cause any problem, perhaps
they are only too strict. However all the issue that can happen not
considering the above problem could lead to different corruptions :(

>
> -Laco.
>

Frediano