FreeTDS Development Group

[LacaK <lacak AT zoznam.sk>]

Frediano Ziglio  wrote / napísal(a):
> 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.

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.