В свежее ядро 4.14.13 не приняли патч, который устраняет проблемы сборки в tools/lib/subcmd/pager.c

На главную!

А ядро по умолчанию с -Werror=restrict собирается? Так то никакой ошибки в коде нет: содержимое in после select() не важно и нигде не используется.

Да, варнинг так или иначе надо убрать, но делать это в LTS, да ещё и в коде, который не относится непосредственно к ядру - явно не приоритетная задача.

Патч для устранения этой проблемы написал Sergey Senozhatsky (Seoul, Korea; Samsung Electronics Co., Ltd.) ещё 1-го января

Ибо нехер патчи с похмелья слать.

А ядро по умолчанию с -Werror=restrict собирается?

Явно эта опция в исходниках ядра не прописана. Вероятно, юзеры GCC до 8-й версии ничего и не заметили. А для GCC 8 это уже серьёзная ошибка.

А попробуй ради интереса собрать вручную тот же код:

#include <stdio.h>

#include <sys/select.h>

int main() {
        fd_set in;

        FD_ZERO(&in);
        FD_SET(0, &in);

        select(1, &in, NULL, &in, NULL);

        return 0;
}

Без ошибок. Заглянул в tools/lib/subcmd/Makefile и присмотрелся к содержимому. Там есть это:

CFLAGS += -ggdb3 -Wall -Wextra -std=gnu99 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fPIC

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

Это говнокод, но, ИМХО, чтобы он привёл к неправильной работе, надо постараться на стороне реализации select() и наложить говнокода ещё и там.

ну, по идее если в функции принимаются два разных указателя, то это два именно разных указателя. иначе на фейхоа? именно об этом и предупреждает компилятор. при оптимизации и распараллеливании выполнения при обращении к таким алиасам может возникнуть банальное UB.

LTS

А какого я вообще решил, что это - LTS-ядро? Оно же текущее стабильное... блин =/