On Fri, Nov 13, 2009 at 11:34:54AM +0300, Damir Shayhutdinov wrote:
> >>> https://bugzilla.altlinux.org/show_bug.cgi?id=22276
> >>
> >> Лучше б ссылку на git дали, чтоб хоть исходники можно было посмотреть.
> >
> > http://tinyurl.com/yzmh82g
> Ок, тогда все понятно.
> 
>  334   char spb[6];
>  335   char *spb_walk = spb;
> 
> Размер буфера - 6 байт.
> Этого не хватает, чтобы вместить unsigned long на x86_64 (8 байт),
> который туда суется через memcpy.
> 
> Для решения можно исправить в строке 334 число 6 на число 10.

Это не решение, а затычка для получения кода, который собирается, но
не работает.

Реализация ADD_SPB_NUMERIC в ibase.h выглядит так:

#define ADD_SPB_NUMERIC(p, data)        {*(p)++ = (ISC_SCHAR) (data); \
                                         *(p)++ = (ISC_SCHAR) ((data) >> 8); \
                                         *(p)++ = (ISC_SCHAR) ((data) >> 16); \
                                         *(p)++ = (ISC_SCHAR) ((data) >> 24);}

"Замена" этого макроса в kinterbasdb делает кое-что совсем другое:

#define ADD_SPB_NUMERIC_DSR(buf_pos, data) \
  memcpy(buf_pos, &data, sizeof(unsigned long)); \
  buf_pos += sizeof(unsigned long);

Т.е., вместо 32-разрядного числа (причём всегда little endian
независимо от платформы) в буфер попадёт число неизвестной разрядности
и с неизвестным порядком байтов.  Увеличение размера буфера просто
маскирует эту проблему.

На самом деле нужно просто заменить кривой макрос ADD_SPB_NUMERIC_DSR
на ADD_SPB_NUMERIC (возможно, обложив его дополнительными приведениями
типов, если вылезут лишние предупреждения).