On 07/03/2019 06:53, Dmitry Yemanov wrote:
> 04.03.2019 23:01, Mark Rotteveel wrote:
>>
>> My question is about the **encoding** in the data buffer obtained
>> from the native client. I want to avoid incorrectly implementing the
>> support in Jaybird. And FYI, In the wire protocol 16 bit integers are
>> encoded as 32 bit integers, and the length of the buffer from
>> fbclient (12 instead of 10 bytes for TIMESTAMP WITH TIME ZONE) seemed
>> to suggest it is in native as well. However as I said in my reply
>> above, it probably is just padded to a multiple of 4.
>
> typedef struct
> {
> ISC_TIMESTAMP utc_timestamp;
> ISC_USHORT time_zone;
> } ISC_TIMESTAMP_TZ;
>
> alignof(time_zone) == 2, sizeof(time_zone) == 2
>
> i.e. time zone (two bytes) is stored immediately after the timestamp
> (no padding)
>
> However:
>
> sizeof(ISC_TIMESTAMP_TZ) == 12
>
> i.e. the whole structure is padded (with two bytes) at the end
>
> I'm not sure whether it's "as desired" though. IIRC, alignment/padding
> is implementation-defined in C++, we're playing on the tricky field.
>
But it how IB/FB always worked. Types are defined in platform specific
way to have correctly sizes. As sizes are fixed they align correctly
with existing platforms.
There may be some luck there, but why would ISC_TIMESTAMP_TZ (for
examploe) be worse than VARCHAR which aligns on two-byte boundary?
A detail however catch my attention. We even internally use things as
SLONG/ULONG instead of int, but ISC_TIME/ISC_DATE is defined directly as
[unsigned] int.
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
