Re: tds_get_size_by_type for SYBMSDATE

Frediano Ziglio  wrote / napísal(a):
> 2014-04-11 8:45 GMT+01:00 LacaK <[email protected]>:
>   
>> Frediano Ziglio  wrote / napísal(a):
>>     
>>> 2014-04-10 8:48 GMT+01:00 LacaK <[email protected]>:
>>>
>>>
>>>       
>>>>> 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.

I understand, but am I right, that such decision is expected?
As precedense I take:
SQL Server       libTDS                          DB-Lib
------------------------------------------------------------
datetime        -> TDS_DATETIME   == DBDATETIME
smalldatetime ->TDS_DATETIME4 == DBDATETIME4
datetime2      -> TDS_DATETIMEALL -> ? (here I expect some struct 
defined at DBLib level (DBDATETIMEALL?))


>  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!
>   
of course ;-)

> 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.
Yes I noticed it, but how can I use it in dblib, without extending 
public API of db-lib ?
(f.e. by adding some new function like we already have written: 
tdsdbdatecrack(...) plus TDSDBDATEREC ?)

Thanks
-Laco.

_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds