то логічно повісити обробку signal з jump куди треба по ідеї (imho)

Логічно її вішають саме туди, де був би try.

if (setjmp(buf) == 0) {
  // try block
} else {
  // catch block
}

А яка і чому потрібна альтернатива?

Не за адресою: я не лаю за посилання на хабр чи навіть на аналог у хамаса.

що окремі обʼєкти це часто дуже малі блоки.

Ну, розмір обʼєктів визначається декількома факторами: необхідністю мати границю через принципове розділення (Страуструп — літак не може бути наслідником двох його двигунів), логічне за рахунок information expert + high cohesion (а інфоциган Мартин зводить в SRP), і оцінка незалежности аспектів реалізації (часто штучна). А, ще повністю штучні посередники через dependency injection.
Якщо використовуються по більшости природні фактори, то не буде надто малих обʼєктів.

Тоді визначення ООП це одна єдина фіча: вказівник на функцію.

На яку з? Я цього не зрозумів. Якщо мова про факт виклику віртуальної функції через вказівник, може бути інший варіант. Я бачив ООП з віртуальними функціями на bash, коли виклик йшов по імені. Але навіть це не однозначна ознака.

Якщо читати Греді Буча, то наслідування реалізації він вважав обов’язковою ключовою рисою.

Є визначення за Граді Бучем.
Є за Аланом Кеєм.
Є ще за кимось.
Варіант Буча зрозумілий, але він занадто орієнтований на конкретний стиль. Я підтримую цей стиль (і вважаю спроби його заборонити, як в Go, марними), але і те, як роблять те ж ООП в інтерфейсі ядра, теж має право на існування.

До речі, я взагалі вкрай мало чую про Граді Буча після ≈2005 року. Якось його наробки вийшли з масової уваги.

Це не стандарт, не кажучи про те, що Microsoft C не підтримує останні стандарти, просто незрозуміла іграшка.

На жаль, да, інші цього не підтримують.
Але не «іграшка». У MS C є одна колоссальна перевага: він не ганяється за тим, щоб заради 2% в нікому не потрібному синтетичному тесті використати ще десяток UB там, де програмісти найменш цього чекають. Вони навіть SSA ввели тільки у 2015-му.

Це інша функція, більше комунікація.

Не плутайте асинхронні сигнали як SIGTERM з внутрішними синхронними, як SIGSEGV. (Їх взагалі не слід було обʼєднувати в один механізм.)

Якщо краще потім оптимізується компайлером

Ні (або я таких не бачив).

чи читається в цілому

Більшости — ні.

Більш цікавий випадок то longjmp.

А в чому різниця з try-catch?

все неправильно, та новина мала б бути першою саме на цьому сайті й з посиланням на оригінальні англомовні джерела...

Ну ось і почни. Де твої новини? В критиканство ми всі вміємо.

(ніколи у цьому контексті не скажеш книга лежить на столі)

Якщо мова з самого початку йшла про цю книгу, то її поставлять на перше місце.

Ти природньо ставиш визначене на початок, невизначене у кінець.

І це не артиклі як частини мови або члени речення. Це саме порядок слів. Ця манера іде ще з загальної індоєвропейської, де теж артиклів не було (і взагалі як для нас була дуже дивна, там складних конструкцій, по типу object clause, в реченні взагалі не могло бути, слова в реченні були всі незалежні і розташовувались в порядку зменшення значення в висловлюванні... але це окрема тема).
І тут не визначене/невизначене. Тут є типовий порядок і нетиповий. Те, що ви сказали про «невизначене», це те, що пікреслюється як нова або принципова інформація. Підкреслення може бути зроблено зміною порядку, а може і інтонацією («Я те́бе кохаю» і «те́бе я кохаю», «я́ тебе кохаю» і «тебе я́ кохаю»). Не можна тут спрощувати.

Англійська майже не має зараз вільного порядку слів і таких інтонацій, і вони компенсують або довгими описами («Thatʼs me who loves you!»), або артиклями. (І не тільки вона, артиклі це типова риса десятків мов.)

Глобальна мітка cleanup де очищується все тимчасове, що нароблено в функції. Альтернатива у вигляді дуже уважного контролю, в якому з return треба на що сказати free, де повернути старе значення і все таке, зламається максимум на пʼятому параметрі, почнуть забувати.
(C++ вирішує це через RAII, Go — через defer, в обох випадках рахує дії вже компілятор.)
Розширений приклад: тут.

Вихід з другого і глибше вкладеного циклу, до сих пір в мові нема тегованих циклів і відповідно break/continue по тегу. Звісно, можна нарожати bool-флагів з перевіркою в умові циклу, і ifʼов в тілі, але навіщо?

якось не задумувався над тим, які трейдофс з тим можливі?

Зараз, мабуть, ніяких, всі можливі недоліки вже пророблені.

В реалізації win32 була ціна на утримання стекового фрейма на кожну функцію, яка хоч якось обробляє винятки. В win64 замінили на табличний пошук, для якого лінкер генерує дані. Це складно, згоден, але все вже вироблено.

В Unix та ж задача була вирішена в ті ж часи в рамках C++, зі схожими підходами (sjlj-exceptions замінені на table-based), тобто код є, зневаджений, треба лише його прилаштувати.

Перевести синхронні винятки, викликані кодом, як то SIGFPE (ділення на 0), SIGSEGV (некоректна адреса памʼяти) і все таке — тривіально. Можна це робити викликом для конкретної нитки. Асинхронні, що приходять з інших ниток/процесів — тут треба подумати, включати чи в той же механізм, але спішити нікуди.

А ось переваги у вигляді поєднання всіх стилів обробки винятків тут можуть бути дуже смачними.

GTK підхід віднесемо до складних задач?

Да.

бо хтось вбачає там деякі OOP властивості на далеких відстанях, хтось ні.

Воно там є. Але реалізація на C вимагає glib-них трюків, після яких комусь таки може здаватись, що ООП нема.

Нічого складного, якщо не лізти в дійсно складні области. Але так зі всім.
Головне, для чого потрібне ООП, це розділення надскладного на таке складне, щоб людина смогла усвідомити, а далі зручно розвивати код. І з цею задачею воно справляється.

В Microsoft C — є. За рахунок SEH як розширення, яке на рівні компілятора підтримано відповідними словами (`__try` і так далі).
І повторюсь, що я б хотів таке бачити всюду, починаючи з Linux, воно в рази зручніше, ніж морочитись з обробниками сигналів і сподіваючись, що longjmp нічого не зламає.

Саме тому в ядрі Linux немає жодного натяку на ООП. ;)

І довго цей міф буде розповсюджуватись?
Обʼєкти — є. Наслідування інтерфейсів реалізаціями — є. Віртуальні функції — є. Вже достатньо.
Нема наслідування реалізації і обмежень видимости при інкапсуляції. Ну так і без них нормальне ООП.
Ви спробуйте якось заглянути в сорці...

— Маэстро, какие ваши творческие планы?
— Ну, я положил на музыку...
— В самом деле? Жаль, очень жаль...

как «переход на линух» сделает пользователя «более независимім»?

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

Я могу сам исправить. Я могу купить подпиливание. Я могу попросить друга. Все варианты.

А миф про то, что я буду всё настраивать, устарел лет на 20. В современной системе на линуксе настройки требует дай бог чтобы 1%, и получается неплохо. Винда же в большинстве случаев просто не даёт сделать, как надо, а лечить её требуется в разы больше квалификация (и опять же боязнь нарушить что-то юридическое).

і зовсім інше діло купка ентузіастів, які після роботи щось там собі пиляють для інших ентузіастів

Прочитайте Спольского. У нього найточніший опис, а не міфи про «купку ентузіастів»:

>> Smart companies try to commoditize their products’ complements.

і все далі як розвиток цеї ідеї.

Щодо UI, він дуже різний. Але особисто мене KDEшний влаштовує значно краще, ніж віндове жахіття. І це тільки порівняння самого DE, а ще є питання, які лежать під ним.

То есть таки совместимости не положено? Я вот помню, что был такой IE6.

до тех пор, пока не умр’т последний юзер, которій помнит зачем єто надо.

Мне бояться, что Наделла придёт убивать?

То-то в этом фирменном стиле давно умерли MS-DOS приложения, хотя у них продолжало быть более чем одного последнего юзера... Или вот я как-то купил на Петровке диск с кучей старых версий винды, так вот косынка и эксплорер от 2.0 на 7-ке крэшились при попытке запуска. Это даже родные приложения, а что говорить о чужих...

Вот кто реально тащит обратную совместимость — это IBM. Ты можеш на SystemZ последней версии с AI сопроцессорами запустить софт 1964-го года от DOS/360, да так, что он вообще не заметит, что обстановка неродная. Причём для несистемного софта вообще ничего особого не нужно, а для системного достаточно BC виртуалки (дешёвый тип). Или на iSeries можно запустить приложение в IL коде от первых версий AS/400, тоже будут работать. Вот это — реальная обратная совместимость.
А у MS — хилый закос...

Можно остановить обновления, даже чтобы не показывались.
Можно сделать автоматическими секьюрити фиксы и явный запрос на остальные.
Вариантов есть. Но если вообще обновление сделали, а у вас стоит соответствующий пакет — значит, оно нужно? Для стабильных веток дистрибутива если обновляют что-то, то к этому есть реальные причины, как правило это баги или секьюрити проблемы.
Отличие от винды в том, что независимо от лицензии ты можешь остановить обновления, если они мешают — и тогда это твоя ответственность. Но он никогда тогда не вылезет с требованием срочного ребута посреди критической презентации, или что там у людей случалось...