Единственное что приходит в голову — это поддержка очень экзотических платформ, где компилятора С99 все еще нет. Мультиклет, например.

Множество проприетарных компиляторов для мелких контроллеров все еще ориентируются на С89.

Так что иногда бывает нужно.

Типы часто в нижнем регистре, и определения переменных посередине функции визуально теряются. Пока пишешь код, всё нормально, но когда возвращешься спустя год, всё печально.

Мне кажется, это вопрос стиля кодирования, а не совместимости со старыми стандартами.

визуально теряются

Решается подсветкой синтаксиса.

Шоб компилять msvc6

Если уже есть много кода, то может быть для сохранения единообразия, а то везде будет в начале блока, но где-то по всему блоку и в for.

Для хорошего кода подсветка излишня.

Многие опенсорсные проекты тащат совместимость исходников с C90.

А некоторые неопенсорсные проекты до сих пор придерживаются ANSI C (С89), поскольку такова цена Ъ-кроссплатформенности.

Если ты можешь позволить себе не использовать C89, то ты можешь позволить себе не использовать C вообще.

Проблем вообще нет, если программируешь словами. Говоришь программистам: ”фичу запили!”

Типы часто в нижнем регистре, и определения переменных посередине функции визуально теряются. Пока пишешь код, всё нормально, но когда возвращешься спустя год, всё печально.

У меня всё равно наоборот.

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

У кого возникает такая практическая необходимость?

вижуалы не умеют в C99.

отпала челюсть

Шо, до сих пор? O_O

поддержка очень экзотических платформ, где компилятора С99 все еще нет.

this. Microsoft Visual Studio, например.

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

Да. Особенно радовала отмаза до 2012ого: «а вам зачем? C типа deprecated, есть же C++».

АААААА!!! Как раззнать это обратно?!

Пишут, что VS2013 supports C99 style variable declarations.

2013! 2013, Карл! Когда космические корабли бороздят, Карл! Помечу топик как решённый, пожалуй. %)

И кому нужен убогий компилятор майкрософт, когда можно gcc/clangом прекрасно все компилировать? Какие живые проекты пишутся на с89?

Да ладно тебе, тебя же не заставляют держать совместимость с MSVS2005. И вообще, там не все так плохо — там даже можно комментировать через // *убежал плакать в угол*.

Спустя год, нихрена не понятно в использовании переменных, если они все кучей объявлены на полэкрана-экран выше

комментарии для лохов?

И кому нужен убогий компилятор майкрософт, когда можно gcc/clangом прекрасно все компилировать?

Я думаю, на практике это выглядит примерно так:

Ой, мы делаем наш-крутой-проприетарный-продукт в VS на крестах или шарпе. Ой, нам надо готовую библиотеку для foobarbaz. Возмём готовую. Ой, она на Си!

Ну моя проприетарщина на работе пишется под «C89 и то, что там может студия десятилетней давности». Дай бог мы в обозримом будущем перейдем на Python 3...

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

комментарии для лохов?

Именно.

Комментарии, в отличие от кода, не подлежат проверке тестами, анализаторами и валгриндом.

В хорошем коде нет нужды в комментариях.

За исключением тех, из которых генерируются маны API потом.

И что, она не слинкуется?

Ну я говорил скорее про случай ТС и опенсорсные проекты.

ну-ну. то-то ты жалуешься, что через год нихрена не понятно

Вопрос на засыпку:Какой стандарт ANSI C в K&R(издатель «Вильямс»,2016)?

Возмём готовую. Ой, она на Си!

ну вот поэтому многие библиотеки и пишутся на C89, а не на C99 — для совместимости с вижуалами.

или пишутся на C++98 внутри, с публичным интерфейсом на c89.

предупреждение: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]

Ха. Недавно компилировал драйвер для usb wifi dongle и тоже с этим столкнулся. А там еще и warnings as errors было :) Мой дядя самых честных правил...

ну-ну. то-то ты жалуешься, что через год нихрена не понятно

Вообще если глубже копнуть, я жалуюсь, что область действия имени зачастую получается неоправданно широкой. Объявлять переменную, когда она действительно начинает использоваться — еще один способ не выстрелить себе в ногу.

Объявлять переменную, когда она действительно начинает использоваться — еще один способ не выстрелить себе в ногу.

зачастую для этого не нужен c99, достаточно нового блока

Отвечаю на свой же вопрос: Судя по введению K&R 2 - C89.

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

Там прямо написано -std=c90 в мейкфайлах?

читаю везде c99. Кажется все забыли про c11.. Или он не выстрелил?

Еще, кстати, из-за мелкомягких: у них поддержка C99 появилась относительно поздно.

C11, норм. Просто суть в том, что с C89 слезать не хотят. А ведь даже тот же C99 привносит кучу полезных *кроссплатформенных* вещей (особенно это касается libc).

// в C89 даже long long нет (и, как следствие, int64_t)

ЕМНИП, в GCC следующий стандарт (C17?) хотят сделать режимом по умолчанию.

Многие опенсорсные проекты тащат совместимость исходников с C90

некоторые и с K&R C :)

Пользуясь случаем хотелось бы спросить нашего гостя из будущего: а когда именно?

на чём нет более-менее современного компилятора, умеющего в C99, уже давно превратилось в археологический артефакт а ля говно мамонта

IMHO это заблуждение. Но лучше поспрашать у эмбедщиков - у них под весьма актуальные железки компилеры «со старыми принципами» :-)

да кстати и что киллер-фичи C99 чтобы их так лелеять?

ЕМНИП, в GCC следующий стандарт (C17?) хотят сделать режимом по умолчанию.

Возможно. По крайней мере текущий стандарт (C11) сейчас как раз является дефолтным.

Кстати, почему все эти авторы новых платформ не хотят просто написать llvm backend? Ведь по сравнению с альтернативами - работы меньше всего. Лицензия LLVM вроде BSD-like, так что вопросов нет. Зато автоматически появляется поддержка последних стандартов C/C++, плюс всякие ObjC, D, Rust и прочие.

Но нет, они все почему-то либо пилят свой велосипед, либо форкают GCC древней версии.

Например потому, что это всё делает пара человек во всём мире, которых эти авторы и нанимают. И этой паре человек хватает gcc древней версии.

Кстати, почему все эти авторы новых платформ не хотят просто написать llvm backend?

Хотят, но архитектура не позволяет.

зачем это на практике нужно?

За тем, что не все компиляторы умеют в более новые стандарты.

Могу пояснить на своем примере: начал писать BuguRTOS на с99, потом стал портировать на stm8 и ... пришлось переписать на более древнем диалекте.

Тред на читай! @ Сразу отвечай!

Да вроди как в 2020 было, ЕМНИП.

2013! 2013, Карл!

Просто в винде на Си, кроме может быть самих программистов микрософта, никто не пишет.