On 07/03/2019 12:47, Dmitry Yemanov wrote: > 07.03.2019 18:25, Adriano dos Santos Fernandes wrote: >> >> 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. > > True, but we lack a guarantee. Alignment may vary even between > different compilers. We're just lucky all the vendors had agreed on > the same rules. >
AFAIK align rules are from the ABI, so compilers will not vary. Otherwise it would be impossible to work even with C libraries like libc or Win32 API. Compilers may change size of types, so int in one compiler may have a size and in another compiler another size. >> There may be some luck there, but why would ISC_TIMESTAMP_TZ (for >> examploe) be worse than VARCHAR which aligns on two-byte boundary? > > For *_TZ types, alignment is not a problem, the size is. Or at least > it may look weird - UTC+TZ together occupy 10 bytes but sqllen returns > 12 bytes. > Should we change TZ to 32 bits then? It will be artificially correct as the others types, I guess. BTW, is this correct in type_alignments? sizeof(Firebird::Decimal64),/* dtype_dec64 */ sizeof(Firebird::Decimal64),/* dtype_dec128 */ sizeof(Firebird::Decimal64),/* dtype_dec_fixed */ Decimal64 seems to be some 64-bit integers in sequence, so won't the alignment instead be sizeof(SINT64)? If we think on FB_MESSAGE (i.e., a struct) things will not match. Also seems problematic SINT64 which is 32-bit aligned in 32-bit arch AFAIK but is defined as sizeof(SINT64) in type_alignments. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
