Разворот C-указателя через .? - это утверждение

Этот указатель теряет не только признак null. Пропадает и длина. Как только обёртка превратила результат в [*]u8, она последнее место, которое знает n. Я бы возвращал p[0..n] как срез, тогда вызывающий получает адрес и длину вместе, и проверкам границ есть с чем работать.

Ещё тип возврата не говорит, кто освобождает память, так что это должен сказать комментарий документации. Память из c.malloc возвращается через c.free, а не через тот аллокатор, который вызывающий обычно носит с собой. Если обёртке не нужен именно malloc, выделение через std.heap.c_allocator с самого начала держит эту пару внутри интерфейса аллокаторов Zig.

Что до выбора ошибки, нужные сведения обычно лежат в errno, и неизменное правило одно, читать его сразу после вызова, пока ничего другого не успело выполниться. Логирование, вызов форматирования, да и вообще любая библиотечная функция вправе изменить его даже без ошибки. В ctypes у Python та же ловушка, поэтому там просят указать use_errno=True и потом читать ctypes.get_errno(), а не саму переменную.

Так что порядок шагов я бы записал такой. Вызов, проверка на null, копия errno в локальную переменную, и только потом решение, в какую ошибку это превращается. Сопоставление может быть switch по нескольким известным значениям с веткой для всего остального, и именно в этой последней ветке больше всего решений.

Со срезом согласен. Обёртка теперь возвращает []u8, а комментарий документации называет c.free способом освобождения, и отдельной фразой описывает путь ошибки, где ничего не возвращается и освобождать нечего.

malloc я оставляю, потому что буфер передаётся C-функции, которая позже может вызвать на нём realloc. Это передача владения в C, и после неё возвращённый мной срез тоже становится недействительным, о чём комментарий теперь говорит.

Только посмотрите, что может вернуть эта ветка для остального. Ошибка в Zig - это просто имя. Полезной нагрузки у неё нет, так что else => error.Unexpected выбрасывает значение errno, которое говорило, что на самом деле случилось. Если значение понадобится потом, ему нужен другой путь, параметр-указатель для результата или структура диагностики, которую передаёт вызывающий, а имя ошибки говорит только, какого рода была проблема.

Известные ветки я бы держал как можно меньше, одно значение errno на одно имя, чтобы читатель мог сверить каждый случай с man-страницей C, не читая остальные.

Похоже на ! в TypeScript, который при компиляции исчезает, только .? в Zig паникует в сборке с проверками безопасности. В ReleaseFast этой проверки нет, так что то, на что вы опирались в тестах, в выпускаемой сборке отсутствует.