В clang15 появилось некоторое количество реально полезных ошибок:

Making all in doc
  CC       src/tramp.lo
../src/tramp.c:262:22: error: 
 call to undeclared function 
 'open_temp_exec_file'; 
 ISO C99 and later do not support 
 implicit function declarations 
 [-Wimplicit-function-declaration]
  tramp_globals.fd = open_temp_exec_file ();
                     ^

Этот код "работает" по чистой случайности, благодаря implicit int, и implicit function declaration.

Ну, вот так - функцию не объявили, но позвать ее можно.

Особенно много такого в gnu software, я так понимаю, благодаря #gnulib, и тому, как они переопределяют функции. Warning про implicit int мне пришлось целиком отключить, потому что с ним ./configure скрипты не работали от слова совсем.

https://github.com/pg83/ix/blob/main/pkgs/bin/clang/lib/cc/ix.sh#L11

Писал, что Столлман и его проект GNU, на самом деле, очень похожи на Гейтса, и MS. #gnu hate speech

Только MS жаден до ваших денег, а GNU - до вашего кода. (я лично считаю, что любая жадность - это плохо, потому что все, в итоге - время, и я уважаю open source, который #charity)

Вот вам интересный факт - GNU переняла тактику MS, которая https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish

У них, на самом деле, есть целый проект про это, называется #gnulib (!= glibc, != glib) (это такая попытка привязать софт к API несуществующей OS, да так, чтобы невозможно было выпилить), но про него надо написать отдельно.

Сегодня - вот про такой забавный #EEE, от гнутого линкера.

https://cgit.freedesktop.org/libbsd/tree/src/setproctitle_ctor.c#n51

Что здесь написано?

Здесь написано, что произвольная so может получить доступ к argc и argv процесса в момент инициализации, для этого достаточно положить указатель на функцию в секцию .init_array. Может ли она их творчески модифицировать, или линкер передает туда RO копию, я хз.

https://maskray.me/blog/2021-11-07-init-ctors-init-array

#maskray пишет, что эту дырень придумали в HP, потом GNU скопировала к себе, а потом разошлось по другим free unix.

"glibc and BSD implementations call the constructors with argc, argv, environ while musl's calls the constructors with no argument"

Классический EEE - запилили странную фичу, а потом конкуренты вынуждены это повторять, для совместимости: "FreeBSD added support in 2012-03. OpenBSD added support in 2016-08. NetBSD made DT_INIT_ARRAY available for all ports in 2018-12"

Не думаю, что BSD добавили это от хорошей жизни, видно, что долго сопротивлялись.

Будни #bootstrap

Есть такая библиотека - libidn2.

На своем сайте, https://gitlab.com/libidn/libidn2, они утверждают, что могут (и что это предпочтительно) использовать системную libunistring (про эту всратую либу надо как-нибудь написать отдельно):

"The Libidn2 library may use GNU libunistring for Unicode processing and GNU libiconv for character set conversion. It is recommended to install them before building and installing libidn2. ... When the recommended libunistring is not available, libidn2 uses internal replacement functionality which increases the size of the library. To use the internal libunistring-replacement rather than the system libunistring (even when deemed to be sufficient) you may use..."

Но вот год назад они стали линковать в себя кусок этой самой libunistring статически (вкомпиливать в libunistring.so) - https://gitlab.com/libidn/libidn2/-/commit/c691cdf09c8c172ebaa5926348b8d41f5fadca4c

Что, зачем, а главное - нахера?

https://gitlab.com/libidn/libidn2/-/issues/104

Судя по всему, у них сломался ubsan на libunistring (это еще одна вечная проблема конвенциональных пакетных менеджеров, что собрать всю приложуху с санитайзером примерно невозможно), и они решили это подкостылить у себя, потому что апстрим (как это принято у проекта #GNU) - #errogant упыри, и не хотят сделать у себя лишний каст по какой-то надуманной причине (а на самом деле, потому что это значило бы признать свою неправоту, что, конечно, невозможно) - https://lists.gnu.org/archive/html/bug-gnulib/2022-03/msg00011.html #gnulib

Мораль?

Ее, как обычно, нет.

#gnulib #rant

gnulib - это такая библиотека от #GNU, которая якобы должна приводить интерфейс системной библиотеки libc, к богоугодному столлманоугодному виду.

У нее есть ряд проблем, которые, в основном, вызваны тем, что у проекта GNU все принято делать через жопу:

* ее не существует в виде отдельной либы. Нельзя собрать libgnulib.a и установить ее к себе на хост

* она поставляется (и разрабатывается) в виде M4 макросов, которые, по странным правилам, генерируют исходники на машине, где собирается то или иное приложение от GNU

* эти псевдоисходники вендорятся каждым проектом от GNU, с патчами от этих проектов

Для этих исходников генерируются (в процессе configure, ага), заголовки, мимикрирующие заголовки несуществующей libc от несуществующей gnu os (!= linux, потому что на linux непустое множество кода, добавляющегося в эти заголовки).

Там куча ifdef, которые либо что-то скрывают из системной libc, либо что-то добавляют (например, функции, которых нет в системе).

Как это работает? Хуево это работает!

Все это барахло очень хрупкО по отношению ко входным параметрам (способам autodetect в configure скриптах фич компилятора и наличия определенных функций в libc), не cross-friendly (например, фишка этой библиотеки - переопределять malloc/realloc, когда системные реализации могут вернуть 0(что разрешено стандартом!), а для этого нужно код реально запустить под target платформу).

Перепоределяется это все с помощью макросов, хотя, казалось бы, нужен тебе realloc с определенным свойством - ну запили ты себе GNU_realloc, и используй консистентно. Это, конечно, слишком прямое решение для проекта GNU.

https://gist.github.com/pg83/55712a369912405fcf9c4063533722eb

Вот вам мой сегодняшний пример, который стриггерил эту волну хейта.

Что тут написано?

configure скрипты вывели несовместимые определение для эмуляции inline в С, и определение для пометки чего-то, как потенциально неиспользуемое.

Вот так выглядит их склейка:

# define _GL_INLINE static _GL_UNUSED

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

Самое безумие этой ситуации - что исправить это невозможно (а, точнее, запретительно дорого), потому что, даже если прийти в gnulib, и исправить это там, то по проектам это говно будет растекаться несколько лет!

Мораль?

Держитесь как можно дальше от проекта GNU, если у вас есть такая возможность.