On 4-3-2019 12:48, Dmitry Yemanov wrote:
04.03.2019 14:40, Alex Peshkoff wrote:
Mark, I'm not 100% sure for TZ id but in all other known to me cases
16-bit integers are sent over the wire in 32-bit network format. I
suppose you should read that id as any other 16-bit value.
Absolutely correct.
To be entirely clear, I'm not talking about what is sent over the wire:
I know there it is 32 bits, I'm talking about the value obtained from
xsqlvar.sqldata from the client, as the client itself performs
endian-specific transformations (from network byte order to system byte
order) on the data.
The only types were shorts are used is SQL_SHORT and varchars. And
looking at an encoded SQL_SHORT, it really uses a buffer of only 2
bytes, and same for varchars, but here the buffer is sufficiently large
that either is possible.
And for big-endian clients this is an important difference. For example,
offset +01:00 (id 1499), if encoded as 4 bytes it would be 0x000005DB,
but as 2 bytes it would be 0x05DB followed by 2 bytes padding (0x0000).
If the wrong assumption is made, this will yield id 0 (offset -23:59)
always.
The same value for little endian is encoded as 0xDB050000 and there it
is irrelevant if 2 bytes or 4 bytes need to be used for decoding (except
for sign, but that is not relevant here as the value is unsigned).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
