История изменений

Ядро же ни с кем посторонним обычно не линкуется. Тут скорее можно сравнить с обычной прогой: ты сам выбрал список подключённых к ней библиотек, сам написан весь её код и в целом не ожидаешь неожиданностей. Кодить колбеки в прогах - более приемлемо, чем в библиотеках. Однако, они всё равно хуже чем ядро: разрабатывал ты с одной версией библиотеки, а кто-то запустил (возможно, перекомпилировав для этого) с другой, и всё, опять непредусмотренный код по соседству.

Этот кто-то сам виноват. Увы и ах!

С другой стороны, ведро – это 40 миллионов строк кода, что сравнимо с размерами всего остального программного кода на компе среднего юзера. То есть, на средней люнекс системе половина всего кода будет запущена в kernel space. Вот такие вот пироги.

Не обязательно, вот представь структуру

А вот если бы в Си были нормальные строки с проверкой границ, такой херни бы не было.

Да, я что-то про него не подумал. Ну, не знаю что тут сказать.

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

Хотя насчёт лютого трешака с зависимостями, когда в проекте транзитивно для сборки тянется по 500-600 библиотек, я полностью согласен. Это лютый ад.

Вместо засовывания указателя на функцию в описание ожидаемого события предпочту засунуть туда int/enum с номером обработчика, и потом switch-ем по этому номеру вызвать нужное (а проблему «мы заранее не знаем какие они могут быть» - решать автогенерацией этого свитча исходя из опций компиляции). Аналог таблицы колбеков при этом компилятор тоже иногда сооружает, но уже в read-only секции кода, а не данных.

А теперь сделай pthread_create таких образом. Ну или обработчик юниксовых сигналов там повесь, я не знаю. Но я хочу это увидеть.

Ядро же ни с кем посторонним обычно не линкуется. Тут скорее можно сравнить с обычной прогой: ты сам выбрал список подключённых к ней библиотек, сам написан весь её код и в целом не ожидаешь неожиданностей. Кодить колбеки в прогах - более приемлемо, чем в библиотеках. Однако, они всё равно хуже чем ядро: разрабатывал ты с одной версией библиотеки, а кто-то запустил (возможно, перекомпилировав для этого) с другой, и всё, опять непредусмотренный код по соседству.

Этот кто-то сам виноват. Увы и ах!

С другой стороны, ведро – это 40 миллионов строк кода, что сравнимо с размерами всего остального программного кода на компе среднего юзера. То есть, на средней люнекс системе половина всего кода будет запущена в kernel space. Вот такие вот пироги.

Не обязательно, вот представь структуру

А вот если бы в Си были нормальные строки с проверкой границ, такой херни бы не было.

Да, я что-то про него не подумал. Ну, не знаю что тут сказать.

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

Хотя насчёт лютого трешака с зависимостями, когда в проекте транзитивно для сборки тянется по 500-600 библиотек, я полностью согласен. Это лютый ад.

Вместо засовывания указателя на функцию в описание ожидаемого события предпочту засунуть туда int/enum с номером обработчика, и потом switch-ем по этому номеру вызвать нужное (а проблему «мы заранее не знаем какие они могут быть» - решать автогенерацией этого свитча исходя из опций компиляции). Аналог таблицы колбеков при этом компилятор тоже иногда сооружает, но уже в read-only секции кода, а не данных.

А теперь сделай pthread_create на вот этом. Я хочу это увидеть.

Ядро же ни с кем посторонним обычно не линкуется. Тут скорее можно сравнить с обычной прогой: ты сам выбрал список подключённых к ней библиотек, сам написан весь её код и в целом не ожидаешь неожиданностей. Кодить колбеки в прогах - более приемлемо, чем в библиотеках. Однако, они всё равно хуже чем ядро: разрабатывал ты с одной версией библиотеки, а кто-то запустил (возможно, перекомпилировав для этого) с другой, и всё, опять непредусмотренный код по соседству.

Этот кто-то сам виноват. Увы и ах!

С другой стороны, ведро – это 40 миллионов строк кода, что сравнимо с размерами всего остального программного кода на компе среднего юзера. То есть, на средней люнекс системе половина всего кода будет запущена в kernel space. Вот такие вот пироги.

Не обязательно, вот представь структуру

А вот если бы в Си были нормальные строки с проверкой границ, такой херни бы не было.

Да, я что-то про него не подумал. Ну, не знаю что тут сказать.

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

Хотя насчёт лютого трешака с зависимостями, когда в проекте транзитивно для сборки тянется по 500-600 библиотек, я полностью согласен. Это лютый ад.