> #define new(t, n) ((t*) malloc_multiply(sizeof(t), (n)))Ну не знаю, мне кажется, в этом случае маленькие буквы - не проблема. Он просто вместо inline-функции использует макрос. Хотя ему сильно повезло, что конкретно тут не будет проблем при вызовах вида new(char, size++).
> несогласных с этой самой приемлимостью — "фанатами" другой крайности?
Я вас не считаю фанатом чего бы то ни было :) Просто в качестве доказательства овнокода вы приводите примеры, которые рассчитаны на "фанатов другой крайности". Причём, примеры, взятые из сомнительных мест и рассчитанные в основном на ненавистников goto и прочих студентов, чья первая реакция - "Аааа!!! смотрите! stpcpy(stpcpy(stpcpy(stpcpy(!!! ГОВНОКОД!".
Вот тот факт, что в каждой второй сторке длина f вычисляется заново, - это уже интереснее. Но тут (отчасти, см. ниже) родовая проблема C: нужно либо функции переделывать, чтобы вместо "const char *" они принимали уже "const char *, unsigned", либо придумать/использовать какой-нибудь "struct easystring { const char, unsigned }".
Ну а дублирование связано с тем, что автор по сути проверяет входные параметры везде, где можно, вместо использования контрактного программирования, когда параметры проверяются только один раз в интерфейсной функции, а вложенные функции доверяют им без проверки. Ну тут понятно, что это из-за того, что вместо продумывания структуры кода и рефакторинга время тратится на ускоренную реализацию нового функционала.
Но, опять же, по своему опыту, я бы не сказал, что код значительно хуже, чем во многих других проектах.
Каково ваше мнение: если код будет переделан согласно тому, что вы выше перечисляли (то есть функционал и политика проекта останутся теми же, но сам код станет качественнее), вы станете положительно относиться к SystemD и его разработчику? Проблема (или хотя бы бОльшая часть проблемы) только в коде?
Лично я сужу о SystemD по коду в последнюю очередь. Гораздо важнее его политика: какой функционал они реализуют (привет, http-серверу для просмотра логов), как относятся к сохранению обратной совместимости, к ошибкам и принятию сторонних патчей, отсутствие стабильной ветки, фактическое навязывание SystemD пользователям, низкое качество не самого кода, а реализуемого функционала.
