Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>>Во-вторых, C в микроконтроллере, ядре ОС и подобных местах — это по определению "уже не C".

M>>С чего бы не C?

ЕМ>С того, что это не полноценный C, состав которого включает ядро языка, стандартную библиотеку и стандартное же окружение. Это подмножество, куда даже ядро может входить не полностью (например, без плавучки), а уж библиотека чаще всего прилично урезана. Соответственно, там может не скомпилироваться или не заработать полностью корректная, платформенно-независимая программа (скажем, POSIX-совместимая), даже если для нее достаточно памяти.

А при чём тут POSIX и C? Это как бы разные вещи. Не, я согласен, у меня printf тоже не линкуется, ему там ещё с десяток вызовов нужно реализовать, но в целом ничего там не урезано, что не относится к вводу-выводу, обычная libc (newlib). Плавающие gcc умеет компилировать софтово (с производительностью, полагаю, будет крайне грустно, но работать будет).

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>>Во-вторых, C в микроконтроллере, ядре ОС и подобных местах — это по определению "уже не C".

M>>С чего бы не C?

ЕМ>С того, что это не полноценный C, состав которого включает ядро языка, стандартную библиотеку и стандартное же окружение. Это подмножество, куда даже ядро может входить не полностью (например, без плавучки), а уж библиотека чаще всего прилично урезана. Соответственно, там может не скомпилироваться или не заработать полностью корректная, платформенно-независимая программа (скажем, POSIX-совместимая), даже если для нее достаточно памяти.

А при чём тут POSIX и C? Это как бы разные вещи. Не, я согласен, у меня printf тоже не линкуется, ему там ещё с десяток вызовов нужно реализовать, но в целом ничего там не урезано, что не относится к вводу-выводу, обычная libc (newlib). Плавающую точку gcc умеет компилировать софтово (с производительностью, полагаю, будет крайне грустно, но работать будет).