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: LacaK <lacak AT zoznam.sk>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] tds_get_size_by_type for SYBMSDATE
  • Date: Mon, 14 Apr 2014 07:33:49 +0200

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.





Archive powered by MHonArc 2.6.24.

Top of Page