>> Это выдранный с мясом кусок кода.  Могу ошибиться, не зная что такое 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, который "переносимый ассемблер".