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