>> Это выдранный с мясом кусок кода. Могу ошибиться, не зная что такое code.
> какой-то код. Неважно что делающий.
> Меня интересуют предыдущие заклинания. Удивительно, но ты третий, кто не понимает, и,
> вероятно, не умеет кодить?Ну, вопрос-то был о потенциальных проблемах, "почему не собирается"? Я ответил почему может
не собираться.
>> Не собралось, подозреваю, на не-gcc. Т.к. __inline__ - нестандартный синоним inline
> не угадал (не-gcc, но он знает про __inline__, да и в gcc
> в любой момент, а может уже, могли сломать точно так же,
> это устаревший вариант семантики). И не совсем/всегда синоним.
Нет, не сломали. И - синоним в gcc. "extern inline" может быть следующей кандидатурой. Эта семантика неодинаково поддерживается стандартами. Но, в принципе, ничего страшного тут нет: писавший подразумевал "у нас есть для этого extern, но вот вам типа inline версия, если хочите".
>> А причем тут K&R?
> вот при том - ты его читал, а реальную проблему в коде
> исправить не можешь
Ну так я ж не телепат! Тебе дали уже два варианта возможных источников проблем.
> современный си и практики программирования на нем
> уже очень далеко ушли от K&R, и книжку давно пора новую писать.
Не думаю. Скорее, тенденция в том, что такие инструкции компилятору сувать
под нос нужно все реже - сам разберется что ему inline. Вкалывают роботы.
Может и пора писать новое введение, но - некому, все померли. Да и C, в отличие
от всяких питончиков - зарос legacy-конструкциями и проще не становится.
> никем неиспользуемому и бесполезному a[++i]+=b
Ну почему-ж неиспользуемому-то? Азы адресации, присваивание...
> cpu-specific код, что я еще забыл
- а это вообще не про C, который "переносимый ассемблер".
