Будут ли внесены изменения в Firebird 2.0 API?

v6y · Сообщение **v6y** » 20 мар 2005, 19:07

Привет всем. Поставил себе Firebird 2.0.
Когда стал компилить свои програмулины с новой fbclient от FB 2.0, то получил предупреждение

../ibapi.c:30: warning: `isc_interprete' is deprecated (declared at
/usr/include/ibase.h:903)

Я так понял API будут меняться. И насколько сильно?

dimitr · Сообщение **dimitr** » 20 мар 2005, 22:21

совместимость старых приложений гарантирована. Пользоваться или нет расширениями API - решать тебе...

v6y · Сообщение **v6y** » 21 мар 2005, 10:51

dimitr писал(а):совместимость старых приложений гарантирована. Пользоваться или нет расширениями API - решать тебе...

Linux Debian 3.0, LI-T2.0.0.10571 Firebird 2.0 Alpha 1

Есть у меня одна функция, вот ее фрагмент:

Код: Выделить всё

...
 char msg[512];
...
 if (status[0] == 1 && status[1]) {
    isc_interprete(msg,(long **) &status);
    *Error=msg;
    msg[0]='.';msg[1]=' ';
    while (isc_interprete(msg+2,(long **)&status))
      *Error+msg;
 }
...

Работала нормально со всеми FB до 2.0

В FB 2.0, если обрабатывается ошибка попытки соединения к несуществующей базе данных, то первый isc_interprete отрабатывает нормально, второй вылетает по "Segmentation fault". Остальные ошибки обрабатываются нормально. Далее, если заменить isc_interprete на новую fb_interpret, то все работает на ура.

Проверять кто нибудь будет? Или самому покопаться на досуге?

v6y · Сообщение **v6y** » 21 мар 2005, 12:35

Или самому покопаться на досуге?

Не удержался, сам покопался, хотя и других дел по горло. Знаю теперь в чем проблема - повезло, что в остальных случаях обошлось без эксцессов. Если кому интересно, фиксится это дело установкой размера msg в моей функции в MAXPATHLEN*2 (у меня это msg[8192]) или использованием fb_interpret. Так что с совместимостью могут таки возникнуть проблемы.

dimitr · Сообщение **dimitr** » 21 мар 2005, 13:19

не совсем понял, причем тут совместимость. isc_interprete() не проверяет размер переданного ей буфера. И никогда не проверяла. Т.е. она всегда может вызвать SEGV при слишком маленьком подготовленном буфере. Именно из-за этого и ввели fb_interpret(), которая безопасна в этом плане.

Ты потенциально мог наткнуться на грабли даже при переходе на минорную версию (напр., v1.5.1->v1.5.2), если там изменялся текст сообщений об ошибках.

v6y · Сообщение **v6y** » 21 мар 2005, 13:36

dimitr писал(а):не совсем понял, причем тут совместимость. isc_interprete() не проверяет размер переданного ей буфера. И никогда не проверяла. Т.е. она всегда может вызвать SEGV при слишком маленьком подготовленном буфере. Именно из-за этого и ввели fb_interpret(), которая безопасна в этом плане.

Ты потенциально мог наткнуться на грабли даже при переходе на минорную версию (напр., v1.5.1->v1.5.2), если там изменялся текст сообщений об ошибках.

Потенциально конечно мог, но размер в 512 байт фигурирует в примерах из API guide и количество данных, возвращаемых одним вызовом isc_interprete действительно никогда не превышало 512 байт (даже 100 по-моему) Поэтому если кто-то, как и я писал свои проги на основе примеров их API Guide, то может сразу же нарваться на подобные грабли. Поэтому предлагаю в функции safe_interpret в jrd/gds.cpp заменить

Код: Выделить всё

     strncpy(s, q, bufsize);
      s[bufsize - 1] = 0;

на что то типа

Код: Выделить всё

    int i;
    ...
    for (i=0; i<bufsize-1 && *q;) s[i++]=*q++;
    s[i]=0;

Заменить придется всего в двух местах, если я чего-то не проглядел. Зато старые программы, декларирующие буфер, размером меньше MAXPATHLEN*2, валится будут только при очень длинном имени файла или алиаса базы данных.

v6y · Сообщение **v6y** » 29 авг 2005, 15:17

Я прошу прощения, что опять поднимаю эту тему.

Реальная задача. Есть демонок, пишущий кое-какие логи в базу в режиме реального времени. При запуске пытается подсоединится к базе, в случае неудачи пишет в свой лог ошибку и тупо пытается самостоятельно эту базу создать и в случае повторной неудачи выходит.

Ну и естественно при использовании FB 2.0, isc_interprete и декларировании буфера размером 512 байт, это дело при попытке подсоединения к несуществующей базе (первом запуске демона) со свистом вылетает по SIGSEGV... И причина этому вот эти чудные строчки

Код: Выделить всё

 strncpy(s,q, bufsize)
 s[bufsize-1]=0

так как bufsize здесь предполагается равным 8192, хотя фактически равен 512.

Уважаемые разработчики, может все таки слегка подправите код? Это ведь займет десять-двадцать секунд максимум...

dimitr · Сообщение **dimitr** » 29 авг 2005, 21:31

угу, помню, что обещал разобраться. Но в пылу борьбы с другими багами запамятовал. На неделе вернусь к этому вопросу и отпишу здесь свое резюме.

dimitr · Сообщение **dimitr** » 20 сен 2005, 14:42

хоть и не на неделе, но дошли наконец руки. Но увы, подтвердить проблему не смог. У меня на всех сочетаниях серверов и клиентов (1.5.x и 2.0), а также файлов firebird.msg сообщения об ошибках идентичные (в случае коннекта к несуществующей базе) и не превышают 512 байт.

Если можешь сообщить детальную инфу со своей машины - благодарствую. А именно, код ошибки в статус-векторе и полное сообщение об ошибке (полученное с бОльшим буфером). Этого мне хватит, чтобы либо разобраться, либо задать новые вопросы

ЗЫ. можешь писать сразу в мыло. Тут это уже никому не интересно, полагаю.

v6y · Сообщение **v6y** » 21 сен 2005, 10:30

dimitr писал(а): ЗЫ. можешь писать сразу в мыло. Тут это уже никому не интересно, полагаю.

Написал на твой sourceforge-вский адрес

iBase.ru Forum

Будут ли внесены изменения в Firebird 2.0 API?

Будут ли внесены изменения в Firebird 2.0 API?

v6y

И все таки...