Skip to Content.
Sympa Menu

freetds - Re: [freetds] tds_get_size_by_type for SYBMSDATE

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] tds_get_size_by_type for SYBMSDATE
  • Date: Fri, 11 Apr 2014 18:44:43 +0100

2014-04-11 8:45 GMT+01:00 LacaK <lacak AT zoznam.sk>:
> Frediano Ziglio wrote / napĂ­sal(a):
>>
>> 2014-04-10 8:48 GMT+01:00 LacaK <lacak AT zoznam.sk>:
>>
>>
>>>>
>>>> 24 ?? On my 64 bit machine is 16 and should be 16.
>>>>
>>>
>>> I did some testing and googling and it seems, that inter - padding in
>>> structures can vary compiler to compiler.
>>> (as C++ standard does not strictly defines binary layout)
>>> It seems, that Microsoft uses his "own padding and sizing" with
>>> bit-fields.
>>>
>>> I did small change in TDS_DATETIMEALL, which gives me now 16 bytes size
>>> (as
>>> in your case):
>>> typedef struct
>>> {
>>> TDS_UINT8 time; /* time, 7 digit precision */
>>> TDS_INT date; /* date, 0 = 1900-01-01 */
>>> TDS_SMALLINT offset; /* time offset */
>>> // HERE "unsigned short" instead of "unsigned":
>>> unsigned short time_prec:4;
>>> unsigned short has_time:1;
>>> unsigned short has_date:1;
>>> unsigned short has_offset:1;
>>> } TDS_DATETIMEALL;
>>>
>>> So now we have: 8 bytes + 4 bytes + 2 bytes + 2 bytes = 16 bytes (seems,
>>> that no padding occurs at end because 16 mod 8 = 0)
>>> Can you change please "unsigned" to "unsigned short" in definition of
>>> TDS_DATETIMEALL ?
>>>
>>> -Laco.
>>>
>>
>>
>>
>> Was thinking the same. Probably even better TDS_USMALLINT
>>
>
> I see, that you have already commited this change. Thanks.
> Now I hope, that this struct will not change "often" in future, else it will
> break applications which will rely on exact binary layout of it.
> (like other languages which link to dblib.dll)
>
> -Laco.
>

Well... this structure is subject to change as long as we want. Or at
least we still didn't decide this is part of the ABI and surely will
be moved in a public header if has to be. libTDS has not a fixed ABI,
this was changed many time ago and surely won't change back entirely.
If in the future a database want to support dates with different
calendars for instance we'll probably change this structure. Obviously
nothing is fixed on store... surely not on software development!

By the way, in libTDS there is a tds_datecrack that can handle this
type extracting informations you need. Is use a TDSDATEREC which is
different from dblib DBDATEREC. This to support every library (for
instance seconds fraction has more precision as you can see from
dbdatecrack).

Frediano




Archive powered by MHonArc 2.6.24.

Top of Page