Восьмеричная система.
Вид для печати
Т.е. оно восьмиричное.
А как отличать от десятичных констант, если записано теми же цифирьками.
С шестнадцатиричным префиксом "0x" понятно же, не то что тут...
Шиза с этим вашим С. :)
Отчего именно ТАК переполняется, надо смотреть как в компиляторе устроен алгоритм преобразования строки в int.
А приведение к long не помогает?
В стиле
#define S_IFMT ((long)0170000) /* file type mask */
---------- Post added at 12:13 ---------- Previous post was at 12:12 ----------
Возможно, лидирующие нули означают восьмиричное число. Я и забыл уже :)
Не, меня то что С как-то сам с этим разбирается устраивает вполне. Просто я сейчас некоторые функции из LIBC на ассемблере переписал, а раньше они были на С. Соответственно начал с константами разбираться и по первости не сразу врубился, потому что там записано прям рядом такое:
#define S_IFCHR 0020000 /* character special */
#define S_IFPIPE 0010000 /* pipe */
и такое:
#define S_VAR1 8 /* something */
#define S_VAR2 9 /* something */
причем первое - восьмеричное, а второе десятичное. :)
Подозреваю что в компиляторе где-то прописано(а возможно так сделано по умолчанию и не меняется) что число из восьми цифр считается восьмеричным, а любое другое десятичным.
неспроста там нули в начале. )
uzi180, есть еще 1 сборка,
https://yadi.sk/d/O-fzoyOOeMZ2q
Переписал syscalls и C0U - это примерно 30% от всего объема работ с LIBC.
С остальным надо разбираться - опять у меня сомнения что взятые от Uzix "исходники LIBC" не в тех регистрах передают параметры в исходники на ASM (т.е. подозреваю что это исходники LIBC не от используемой мной HitechC v3.09, а от более новой). Не проще ли будет из имеющийся CP/M-овской LIBC от v3.09 выгрузить OBJ для стандартных метематических и mem* функций и затянуть в новую, а заново добавить, скомпилировав, только UZIX-зависимые функции (ну или которые в исходниках на pure С)?
Пока сделаю небольшой перерывчик на обдумывание.