Board.KolibriOS.org

Спасибо что поправили.

Как вы считаете может быть include директорию и libc.obj переместить в ktcc/bin. Тогда таким образом можно будет использовать параметр -B и не указывать постоянно include path в ручную.

А можно ли как то ее использовать с kgcc/kld как раньше?

Если заморочится... То наверное да. Но так как Coldy сделал автоимпорт, то смысла не вижу. Да libc.obj всё ещё плоха в плане stdio. Файловый ввод/вывод работает слишком медленно.

Не забывайте, что tcc - это еще и линкер, т.е. можно использовать любой компилятор, а линковку делать tcc, но ему нужны объектники ELF на входе (при необходимости их можно получить через конвертер objconv). Сейчас tcc адаптирован для автоимпорта. Последние изменения еще больше повысят удобство (единственное нужно сделать адаптацию заголовков) и даже сделают программы более компактными.

сделать адаптацию заголовков - готово

Теперь функции - это функции, а не указатели (как было раньше).

Обнаружил ошибку в функции sscanf. Не обрабатывается символ * (пропуск) в строке форматирования.
Пример: В результате i == 119 вместо i == 5.
В результате n == 2 вместо n == 1.
Предлагаю исправление на проверку.

Исправленный файл приложил, его нужно загрузить в /programs/develop/ktcc/trunk/libc.obj/source/stdio/format_scan.c. Загрузите на SVN (у меня нет доступа к нему).

Upd. Добавил исправление к вычислению результата. Пропущенные аргументы не учитываются в результате. Upd2. Отправил в SVN самостоятельно.

Замечательно! На один баг меньше)

Нашёл баг опять же в проклятой scanf и sscanf. Форматирование "%o" работает не правильно. Вместо конвертации в восьмиричную систему она преобразует в шестнадацатиричную.
Что то подозреваю, что в этой замшелой реализация из libck не только тут баг.
Думаю нужно попытаться адаптировать sscanf из musl libc.

С printf, scanf есть проблема - если их полностью реализовывать (или портировать из glibc итп), они получаются монструозными и программы - большими по размеру бинарников.
Потому я переписал(или дописал, не помню) упрощенную версию.
И потому есть con_printf, еще упрощенней, который из console.obj

В конце концов tcc - "игрушечный" или учебный компилятор, зачем ему 100% соответствие?

PS. Что то я смотрю, всю libck перековеркали как бог черепаху, непонятно зачем. Тесты хоть проходит?
ЗЫ2. Еще и поменяли каталоги, навернув всю историю изменений в SVN (

Рад видеть через столько лет ... libck больше нет... libc.obj хотя бы немного пытается соотвествовать стандарту с99. libck не соотвествут никаким стандартам. А ещё libc.obj динамическая либа так что на размер программы это ни как не повлияет.
Только ненадо говорить что я всё сломал и испортил.

Так без истории непонятно, сломал ты чего или починил.

Учись пользоваться СКВ, они для командной работы придуманы

ЗЫ. git умеет отслеживать переносы файлов, SVN - нет

libck писалась на соответствие https://cplusplus.com/reference/clibrary/

Ты ещё не понял, что я ничего не перемещал. libc.obj это не твоя библиотека. Это самостоятельная либа которую мы собрали из кусков musl, pdclib, glibc и да там есть небольшие куски из твоей libck.

Ну libck не моя, ее писали первоначальные портировщики tcc. Я лишь подтянул хвосты.

Я понял, еще один франкенштейн =)

Мда, иначе чем вредительством я назвать не могу.

Моя одна из последних версий conio.h https://pastebin.com/KWf9Gp0f

Теперь какой то огрызок

Пусть это будет вредительство. Хорошо вернуться спустя столько лет и начинать критиковать ...