Hacker News Digest

Показываю, как в C сделать обобщённый контейнер maybe, который безопасно возвращает результат, если он есть, и сообщает об ошибке, если её нет.

#define maybe(T) struct { bool ok; T value; }
#define maybe_just(T,x)  { .value = (x), .ok = true }
#define maybe_nothing(T) { .value = (T){}, .ok = false }

static maybe(int) divide(int a, int b) {
    return (b != 0) ? maybe_just(int, a / b) : maybe_nothing(int);
}

Вызов:

maybe(int) p = divide(6, d);
if (p.ok) printf("%d\n", p.value);
else       puts("division by zero");

Чтобы не забыть проверку, добавляем макрос maybe_value, который при ошибке возвращает нулевой указатель, ловим его санитайзером:

#define maybe_value(x) \
    (*({ auto _p = &(x); _p->ok ? &_p->value : (void*)0; }))

Но деление на ноль — не единственная проблема. При делении INT_MIN / -1 возникает переполнение. Исправляем:

maybe(int) safe_divide(int a, int b) {
    if (b == 0 || (b == -1 && a == INT_MIN))
        return maybe_nothing(int);
    return maybe_just(int, a / b);
}

Компилируем с -fsanitize=signed-integer-overflow,integer-divide-by-zero -fsanitize-trap=undefined -O2. В ассемблере не остаётся пути к ud2, то есть оптимизатор доказал: переполнения и деления на ноль нет.

Это не делает весь C «безопасным» (жизненный цикл указателей и арифметика не покрыты), но для ограниченных задач подход работает.

• Критика: реализация не заставляет проверять результат, теряя главное преимущество Maybe.
• Ассемблер: GCC выдаёт почти тот же код, что и для std::optional, но не возвращает результат в регистре.
• UB: «пустой» lvalue в случае ошибки вызывает неопределённое поведение; автор полагается на null-sanitizer.
• Эргономика: предлагают добавить and_then/or_else и сделать тип непрозрачным через макросы.
• Почему не другой язык: встраиваемые/фирменные проекты часто ограничены только C или ASM.

Введение

Я часто использую отладчик, но привык и к выводной отладке, особенно в юнит-тестах. Хотелось улучшить её и чаще подключать отладчик.

Улучшение выводной отладки

Главная проблема — «шум»: в цикле интересна одна итерация, а печатается всё. Или удобнее читать форматированную структуру, но приходится раскидывать print’ы по коду. В Zig тесты используют error’ы, значит можно печатать только при падении теста через errdefer:

test { errdefer std.debug.print("{f}", .{ast}); // ... }

Так контекст появляется только при ошибке, без засорения лога.

Запуск тестов в отладчике

Просто запустить seergdb или gdb -tui неудобно: тестовые бинарники лежат в zig-cache. Трюк из ziggит: build.zig может запускать команды и передавать путь артефакта:

// seergdb — GUI фронтенд для gdb const debugger = b.addSystemCommand(&.{ "seergdb", "--run", "--" }); debugger.addArtifactArg(exe_unit_tests);

const debug_step = b.step("debug", "Run unit tests under debugger"); debug_step.dependOn(&debugger.step);

Это запускает правильный бинарник. Но отладчик сработает лишь на брейкпоинте или панике, тогда как раннер тестов «проглатывает» ошибки.

Комбинация трюков

Добавим @breakpoint через errdefer:

test { errdefer @breakpoint(); }

Так мы попадаем в точку ошибки, видим контекст и вывод std.testing.expect*. Минус: при zig build test отчёт показывает падение всего шага тестов, а не отдельных кейсов. Нужна возможность включать брейкпоинты выборочно.

Условная компиляция

Через build options пробрасываем флаг, решающий, вызывать ли @breakpoint в тестах.

Минимальный скрипт сборки, запускающий тесты, дополняем опциями:

const std = @import("std");

pub fn build(b: *std.Build) void { const target = b.standardTargetOptions(.{}); const optimize = b.standardOptimizeOption(.{});

const lib = b.addModule("zig-test-patterns", .{
    .root_source_file = b.path("src/root.zig"),
    .target = target,
    .optimize = optimize,
});

const options = b.addOptions();
options.addOption(bool, "debugger", false);
lib.addImport("config", options.createModule());

const mod_tests = b.addTest(.{ .root_module = lib });
const run_mod_tests = b.addRunArtifact(mod_tests);

const test_step = b.step("test", "Run tests");
test_step.dependOn(&run_mod_tests.step);

}

В коде тестов:

const std = @import("std"); const config = @import("config");

test "errdefer @breakpoint()" { errdefer if (config.debugger) @breakpoint(); return error.FixMe; }

test "no breakpoint" { return error.FixMe; }

zig build test — без брейкпоинтов. Но менять значение флага так — значит пересобирать build.zig. Добавим опцию прямо в систему сборки:

var options = b.addOptions(); const use_debugger = b.option( bool, "debugger", "Enables code intended to only run under a debugger", ) orelse false; options.addOption(bool, "debugger", use_debugger);

Теперь можно переключать поведением командой:

zig build -Ddebugger test

И, при желании, привязать шаг запуска отладчика к этому флагу.

• Участники хвалят согласованность базовых конструкций Zig: минимализм синтаксиса и мощь comptime позволяют элегантные решения без излишней сложности.
• Особый интерес вызвал errdefer: многие отмечают, что это упрощает тесты и отладку; звучит мнение, что такую возможность «стоит иметь каждому языку».
• Обсуждают практики отладки: полезны советы по интеграции дебаггера в build.zig, что избавляет от ручного поиска исполняемого файла в кэше.
• Поднимается вопрос об ошибках без полезной нагрузки в Zig: при парсинге (например, JSON) типовые ошибки вроде UnexpectedToken недостаточно информативны; интересуются паттернами передачи дополнительного контекста.
• Есть замечание о смешении стилей именования (camelCase в stdlib vs snake_case у автора), что может сбивать с толку.
• Отмечают эстетику сайта и блога: шрифты (Berkeley Mono), цветовую схему и ретро-оформление — «как в старых DOS-играх».
• Проводится параллель с D: аналогичная идея реализована через scope(failure), что подчеркивает общность концепции.