libini + libio

Discussing libraries simplifying applications development
  • You're good on luck my friend!
    I started to write one on the Wiki yesterday, i'll give you a link when it's done ;)
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • It's great! A tutorial of libini using is what I need in my Shell project. Please write also how to use libini with gcc (MinGW). Write prototypes for functions and interface to init procedure. I wrote an own prototype (with asm("")) but it crashes the program. Btw why fastcall in init procedure is used? (stdcall is used in other functions, am I right?)
  • I have no experience with GCC in kolibri, and dont have plans to use it in the near future, but i'll do my best trying to explain libINI in a common way..

    The article will be placed at http://wiki.kolibrios.org/Libini, but its incomplete and probably has bugs right now.

    PS: Albom, just curious, why do you write your shell in gcc ?
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • Нашел серйозный глюк в библиотеке libio
    При вызове функции file.close с нулевым указателем не делается проверка на то что он нулевой и в результате затирается системная память.
    Глюк может проявлятся в случаях когда программа использует библиотеку libini, но при этом самого файла ini на диске нет. В таком случае идет попытка закрыть нулевой указатель на файл, что приводит к последующему вылету приложения, которое пыталось считать настройки из несуществующего файла.
    Предлагаю такой вариант функции file.close :

    Code: Select all

    ;;================================================================================================;;
    proc file.close _filed ;//////////////////////////////////////////////////////////////////////////;;
    ;;------------------------------------------------------------------------------------------------;;
    ;? Close file                                                                                     ;;
    ;;------------------------------------------------------------------------------------------------;;
    ;> _filed = file descriptor (see `file.open`) <InternalFileInfo*>                                 ;;
    ;;------------------------------------------------------------------------------------------------;;
    ;< eax = -1 (error) / file pointer position <dword>                                               ;;
    ;;------------------------------------------------------------------------------------------------;;
    ;# call `file.err` to obtain extended error information                                           ;;
    ;;================================================================================================;;
            cmp eax,32
            jb .exit_error
            mov     eax, [_filed]
            mov     [eax + InternalFileInfo.Mode], 0
            mov     [eax + InternalFileInfo.FileName], 0
            invoke  mem.free, eax
            xor     eax, eax
            jmp @f
            .exit_error:
            or      eax, -1
            @@:
            ret
    endp
    Если никто не против, то обновлю файл libio.asm . У меня просто вызывает сомнение коментарий:
    eax = -1 (error) / file pointer position
    Т. е. судя по коментарию в случае ошибки должно вернуться -1, но я не знаю стоит ли это значение возвращать ? Просто судя по всему оно вообще нигде не использовалось, нужно ли оно ?
    Т. е. строка в моем коде:

    Code: Select all

    or      eax, -1
    вроди бы и не нужна ...
  • [sarcasm]Ещё более страшный глюк в libio: если в file.close передать взятое с потолка число, то file.close просто уронит программу!!![/sarcasm]
    Сделаем мир лучше!
  • CleverMouse wrote:Ещё более страшный глюк в libio: если в file.close передать взятое с потолка число, то file.close просто уронит программу!!!
    делаем вот что :
    1) из папки rd/1/develop удаляем файл t_edit.ini
    2) запускаем программу t_edit
    3) тянем скроллинг вниз
    ... и программа завершается с ошибкой ...
    Я почти весь загрузочный код в t_edit облазил, пока не понял что ошибка в самой библиотеке libini а не в программе t_edit.
    Я более чем уверен что подобный фокус сработает с любой программой использующей ini файлы.
    После сделанных мною исправлений глюк пропадает.
  • Ну так тогда это баг в libini, а не в libio, и исправлять его надо в libini.
    Сделаем мир лучше!
  • ревизия 3130
    Исправил в libio, потому что в libini функция file.close вызывается 8 раз. Также по правилам программирования попытка удалить объект с нулевым указателем не должна заканчиватся ошибкой. Учитывая выше сказанное исправил в libio.
    Также немного оптимизировал файл editbox.mac.
  • Обе причины не принимаются. Копипаста в каком-то коде - не повод ставить костыли специально для этого кода где-то в нормально работающем месте. Про правила программирования я предлагаю порассказывать авторам libc:

    Code: Select all

    $ cat 1.c
    #include <stdio.h>
    int main() { fclose(NULL); return 0; }
    $ gcc 1.c && ./a.out
    Segmentation fault
    
    Я откатила изменения в libio в r3131 и закоммитила фикс в правильное место libimg. Заодно выяснилось, что в ini_set_str была утечка памяти.
    Сделаем мир лучше!
  • CleverMouse wrote:Заодно выяснилось, что в ini_set_str была утечка памяти.
    это очень хорошо что оно выяснилось
    CleverMouse wrote:Про правила программирования я предлагаю порассказывать авторам libc:
    Большую часть судя по авторству написали diamond и mikedld, оба покинули проэкт. А вот что я нашел на wiki в описании функции file.close
    file_close

    Закрыть файл.

    Прототип:
    proc file.close _filed

    Аргументы:
    _filed → InternalFileInfo*
    дескриптор файла (см. file_open)

    Результат:
    eax → dword
    -1 (ошибка) / 0
    Судя по всему авторы планировали что при каких-то случаях будет возвращатся -1, вот только теперь не ясно при каких. Видимо wiki прийдется поправить. Вообще не понятно что должна возвращать функция file.close ? Сейчас она всегда возвращает 0.
  • Большую часть судя по авторству написали diamond и mikedld, оба покинули проэкт. А вот что я нашел на wiki в описании функции file.close
    Я так понимаю, имелась в виду POSIX.1 C Library
    Библиотека libio ставит перед собой цель сделать ассемблерные функции, эквивалентные файловым операциям из LibC. Соответственно,
    int fclose( FILE *stream );

    Closes the given file stream. Any unwritten buffered data are flushed to the OS. Any unread buffered data are discarded.

    Whether or not the operation succeeds, the stream is no longer associated with a file, and the buffer allocated by setbuf or setvbuf, if any, is also disassociated and deallocated if automatic allocation was used.
    Parameters
    stream - the file stream to close
    Return value

    ​0​ on success, EOF otherwise
    Однако, fclose при передаче неверного указателя вызывает сегфолт на всех проверенных мной библиотеках libc - newlib, GNU libc (Linux), GNU libc (mingw), libtcc1. Если копнуть глубже, видимо, так и должно быть по стандарту.
  • Хм, банальное гугление https://www.google.com/search?q=fclose(NULL) - дает ответ, что fclose(NULL) есть undefined behavior, и закрывать можно только 100%-валидные потоки.
  • Правильно ли я понял по коду, что, если _callback возвращает 0, то enum_sections и enum_keys немедленно завершаются?
    Можно я допишу это в Wiki?
  • А есть полный перечень функций библиотеки? И еще, есть ли общий способ узнать имена функций любой библиотеки?
    to infinity and beyond
  • Who is online

    Users browsing this forum: No registered users and 2 guests