Комментарии 9
Желтоватенько, конечно. Если errno определена препроцессором, значит ее реализация «встраивается» в бинарники во время компиляции, так ведь? То есть все уже собранные бинарники перестанут работать корректно если реализацию поменять.
Вопрос: какого масштаба апокалипсис должны найти в текущей реализации чтобы такое изменение протащить через все код ревью в прод? Сломавшийся при этом GO будет явно меньшей проблемой, да и ту можно починить «скопировав» реализацию ещё раз и все пересобрав.
Ах да, .h файлы - это вполне себе documentation-as-a-code в таких случаях. Даже с комментариями иногда.
Собранный бинарник в мире UNIX вообще не считается чем-либо авторитативным. Гентушники же не просто так придумали emerge world.
Если у вас "добрый" вендор, то он хотя бы бампнет so-version, и у вас бинарник пожалуется на отсутствие символа. (Большинство вендоров "добрые")
Но бывает ещё хуже -- бинарники будут запускаться, но... крашиться или выдавать неверный ответ.
В мире UNIX авторитетен только код, и, собственно, это была одна из причин, почему Столлмана так взбесил тот закрытый драйвер для принтера.
Тут другой момент: в каждой UNIX-подобной системе реализация этих вызовов разная, поэтому, если мы охватить множество платформ, нам придётся делать много системо-зависимых вызовов. Одно дело — просто перекомпилировать враппер, и совсем другое — поддерживать реализацию всего этого самостоятельно, что заведомо провальная идея.
Претензия же у людей к тому, что glibc, которая является обёрткой над системными вызовами, сама предоставляет API, к которому снова нужно писать обёртку из более высокоуровневых языков, что очень неудобно.
Где, в частности, написано:
Switching Go to use the libc wrappers (as is already done on Solaris and macOS) is something that De Raadt would like to see.
Т.е. в Solaris и MacOS, которые как раз UNIX(tm), Go уже работает с системными вызовами через libc, не потому что так надежнее, а потому, что если в ОС запрещены системные вызовы не из libc (для защиты от ROP), то по другому просто работать не будет:
The idea is to restrict where system calls can come from to the parts of a process's address space where they are expected to come from.
До тех пор пока ограничений нет — нет разницы откуда вызывать syscall, если ограничения реализованы — то по другому просто не получится (attacker would need to be able to call the wrapper, which is normally at a randomized location), а не потому что «так надежнее».
И теперь Teo De Raadtt хочет, чтобы в его home grown OpenBSD было так-же, честь и хвала ему за за это.
Автор, имей совесть, удали этот мусор с хабра.
Ничего, будут работать.
Ибо это разные ОС.
Нет никакого so hell, есть ABI.
Вот, качаем релиз: github.com/boramalper/magnetico/releases, и не можем его запустить на Debian 10, ибо нет такой версии libc.
уже вторая статья про неправильность errno
но
errno
давно совместима с тредами- программы на C++ отлично совмещаются с
errno
То есть статьи эпохи когда в Linux/BSD внедряли треды и ещё не доделали под них errno. Но эта эпоха была ну очень давно же.
Заметки о Unix: надёжная работа с API C-библиотеки Unix возможна только из программ, написанных на C