K&R C депрекейтят

Всё правильно делают. Даже TCC (Tiny C Compiler) умеет C99.

из-за проблем совместимости с некоторым сторонним кодом мы планируем окончательно перейти с K&R на ANSI C

Ну и хорошо. Сейчас везде всё с -ansi и так компилится. И только не надо начинать снова это песню про якобы обучение. В 2025 году изучать громоздкое и неинтуитивное объявление параметров функций по K&R, которое совершенно точно сразу после этого придётся закопать — глупость. Даже на Паскале до сих пор пишут реальные проекты, в отличие от этого.

Это чисто формальность. Не стоит обращать внимания. Это скорее обращение к промышленности, там могут стоять машинки/станки крутящиеся десятками лет, но всё же требующие корректировки, обновлений и так далее и тут просто призыв мол «вы если чё там почешитесь по поводу актуализации кода, а то мало ли». В любом случае физически нет аааааабсолютно никаких проблем и преград использовать самый самый старый диалект, хоть до второго пришествия, как бинари умеющие это, так и исходники из которых собраны эти бинари, уж для Си с его 1000500000 компиляторами на любой вкус цвет и архитектуру всегда найдутся. Проблемы могут быть на стыке, когда часть кода на C11 обновили, но вот некая другая часть не трогается и просто попутно собирается. Вот для таких это и уведомление, мол, ну вы там если что знайте что, ну вы поняли.

А в целом поправить Сишный код с самого наидревнейшено диалекта, на самый распоследний вообще задача примитивная при этом не пострадает ничего, ни оформление ни суть. Вообще мелочи, старый диалект это больше про форматирование чем про синтаксис.

Стриггерится тут можно разве что на слово «Deprecation», вместо него надо было писать просто «Notice», но так промышленников не испугаешь и они не зашевелятся =)

Вообще зря это всё придумали. У K&R гораздо красивей и логичней всё смотрится. Деградация налицо.

Всегда будут компиляторы которые будут всё это уметь, пусть там стандартизаторы в ISO хоть на голове прыгают. Это не имеет никакого значения. Это всё формальности, бюрократической организации. Но, такая у них работа они вынуждены что-то фиксировать. Забей. Стандарты будут реализованы, как и очередные расширения сверх их, так и поддержка того что было раньше, пока это хоть кому-то да нужно (из тех кто реализовывает)

Когда ты слышишь что кто-то заявляет что что-то устарело и он его депрекетит с носиком кверху и ножкой в сторону. Скажи в слух COBOL три раза, и отпустит, так как его депрекейтили ещё до рождения депрекатора и будут депрекейтать после.

we plan to finally switch from K&R to ANSI C
C89

Самое время.

Что за заголовки? В России депрекейтят K§R C - вот так правильно.

Я не понял, они получается две копии кода держали с разными заголовками что ли?

Нет, одну - sendmail написан на K&R C получается, по крайней мере был до этого объявления.

Начинать обучение с C вообще нельзя.

K&R

Больше удивляет, что этот копролит всё ещё встречается.

ANSI C

Шило на мыло. Сразу бы поднимали до самого современного стандарта.

ещё встречается

Хм, хотел про zlib написать что он никуда не переходит, а там тоже:

Changes in 1.3 (18 Aug 2023)
- Remove K&R function definitions and zlib2ansi. 

Началось )

Ага, настолько классный стиль, что из-за него нельзя написать

in func() __attribute__((constructor)) {
 ...
}

Потому что парсер до сих пор (!) ожидает между ) и { список аргументов функции. Из-за этого атрибуты функций можно размещать только до декларации имени. ЖСС до сих пор, даже в C23 не может распарсить такое (хотя в С23 синтаксис размещения переменных после декларации запрещён) - потому что старый парсер.

Ну и слава богу, что нельзя. Как тебе вообще в голову пришло, что это должно быть возможно? Ты просто случайно токены местами переставляешь и жалуешься, что это не работает или что?

Описатели функции должны быть рядом с её типом, очевидно, и K&R тут ни при чём. Если где-то поддерживается засовывание атрибутов в конец - ничего хорошего.

Это, разумеется, не значит что я одобряю K&R синтаксис, мне он тоже не нравится.

А ничего, что по стандарту нет разницы, где ставить?

int func(
   __attibute__((unused)) int a,
   int b
) {};

эквивалентно

int func(
   int a __attribute__((unused),
   int b
) {};

Только второй вариант позволяет сразу увидеть, что там за переменная. То же самое с функциями:

void _init(void) __attribute__((constructor)) {

}

Читается много лучше, чем

__attribute__((constructor)) void _init(void) {

}

Особенно, если там кроме этого тега ещё несколько, типа сегмента или приоритета.

А ничего, что по стандарту

Да и плевать, что там по твоему стандарту. Правильный стандарт - это спецификация gcc.

Только второй вариант позволяет сразу увидеть, что там за переменная. То же самое с функциями:

Нужно макрос сделать на UNUSED и всё будет норм. Это громоздкие __attribute__ всё равно нечитабельны.

Читается много лучше, чем

Нет не лучше. Описание слева, название справа. Ты ты ещё static/extern предложил вправо переставить.

Много лучше читается функция без всяких атрибутов. Просто возьми и вызови её в main. Не надо из C делать Java.

Если уж хочется атрибут, то его надо писать на отдельной строке перед функцией.

[[constructor]]
void init() {

}

А имена с подчёркиванием вообще зарезервированы, если что. Ты бы ещё _start написал.

K&R определения функций deprecated в C23. Для gcc 15 С23 уже по умолчанию.

Меня больше удивляет, что кто-то пользуется sendmail до сих пор.

Меня больше удивляет, что кто-то пользуется sendmail до сих пор.

Вангую царь это откопал во фряхе, оно там в базовой системе было.

да так-то даже ANSI в чистом виде уже изрядная древность и редко где попадается.

а определения функций в старом формате я нигде не видела, кроме какого-то одного очень древнего софта. вот даже не вспомню навскидку, где. кажись, как раз где-то в агентах мыла. может, даже этот самый sendmail и был. и больше точно нигде.

Много лучше читается функция без всяких атрибутов. Просто возьми и вызови её в main. Не надо из C делать Java.

Ого, человек, который на С не писал ничего сложнее студенческих работ.

А имена с подчёркиванием вообще зарезервированы, если что.

Цитирую:

“All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.”
“All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.”

Есть тут underscore + uppercase? нету. Вот static опустил, да, не хотел захламлять и так длинную строку примера.

Ты английский не понимаешь что-ли?

“All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.”

Это значит, что функцию так называть нельзя. У функции file scope. Ты можешь называть так локальные переменные, поля в структуре, не более.

Я в конце 1980-х уже учил С по ANSI (до принятия, но по предложенной версии). Так что, даже удивительно.

Да нет, это ты кажется не понимаешь. Зарезервированы - это не значит что нельзя называть, это значит что им указано целевое использование. В данном случае - локальные (static) идентификаторы внутри файла. Если бы целевым использованием было «внутренние дела компилятора или libc» то да, называть было бы нежелательно (но в целом никто не запретит, пока компилятор с ошибкой не упадёт если попадёшь удачно).

Я кстати эту цитату первый раз вижу, но, видимо из опыта чтения чужого кода, такое же восприятие сложилось - подчёркивание это локальное что-то. Хотя ещё их удобно использовать для полей структур которые надо чуть-чуть спрятать от случайного использования.

Нет, это ты не понимаешь. Зарезервированы это значит они могут использоваться в реализации libc, например. Самый известный пример это _start. Но может быть любое другое использование в любом хедере, например. Поэтому не нужно использовать такие идентификаторы в своей программе. Они зарезервированы для внутренних нужд компилятора или стандартной библиотеки.

А какие имена ты будешь использовать для внутренних или внешних идентификаторов - это твоё дело. Главное не начинай их с подчёркивания, если не хочешь проблем.

Нет не значит. Тогда было бы написано «зарезервированы для libc». Зарезервировано всегда для чего-то конкретного, и если ты не видишь или не смог прочитать/перевести для чего именно - считай что ты вообще никакой информации не получил.