Означает ли это, что Linux будет официально поддерживать компиляцию в Clang в ближайшем будущем?

Нет. Это только означает, что Линуса беспокоит качество кода

Например

огласите весь список, пожалуйста

Что же ещё мешает компилировать ядро в Clang?

VLA и VLA внутри структур это разные вещи.

В письме Линуса приводится пример обычного VLA (https://github.com/tinganho/linux-kernel/blob/f1349b033d5faee3682eea244a7cb4d...)

USING VLA'S IS ACTIVELY STUPID! It generates much more code, and much _slower_ code

VLA по сути стандартизация для alloca(). Единственное что странно это то, что они заставили нормально реагировать sizeof() на такие массивы, приходится выделать sizeof(size_t) памяти еще

Хз зачем гореть так с VLA, без пруфов эти вбросы с «ACTIVELY STUPID» полностью глупы.

ну а структуры с разным размером это дичь, да. Никому нафик они не нужны

Ничего, но и не заставляет проводить его к совместному с шлангом состоянию)

Ну тогда тем более ему не нравятся VLA внутри структур. Так что же мешает поддерживать компиляцию Linux другими компиляторами, например Clang? Ведь изначально UNIX переписали с ассемблера на C ради переносимости и в дальнейшем делали акцент на то, что UNIX - это переносимая система.

линукс компиляется переносимым компилятором GCC

Это ничего не означает.

и вообще, руки прочь от VLA!

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

А причём тут ассемблерные вставки? Разве Clang их не поддерживает или использует другой ассемблерный синтаксис?

arm/arm64 собирают шлангом, до тех пор пока не споткнуться например на ассемблерные вставки

Шланг здесь не нужен. А то gcc ещё загнётся ненароком

Загвоздка именно в ассемблерные вставках, например, в модификаторах, а не в самом синтаксисе

Это не тебе решать. Кстати, с некоторых пор в ядре стали встречаться коммиты, сделанные для Clang. К чему бы это?

И не тебе. Сказать-то что хотел?

Перечитай сообщение ещё раз.

И? Новой информации ноль

Потому что ты обиделся как юная школьница. Ещё раз, среди коммитов ядра уже сейчас есть связанные с Clang.

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

Нужны, если используются только по указателю и последний элемент - массив данных типа строки.

На что обиделся? И причём здесь коммиты, связанные с clang?

На то, что не тебе решать. А коммиты эти при том, что Clang в ядре таки нужен. Твой КО.

Начиная с C11 поддержка VLA компиляторами опциональна.

А коммиты эти при том, что Clang в ядре таки нужен [кому-то]

Так я за себя говорил. Поэтому, действительно, КО и мой вопрос ещё актуален.

Вот поэтому не тебе решать.

Да, уж. Так и не раскрыл свою мысль. Ну не хочешь - и ладно

Научись читать ;-))

Или ты научись писать )

А может кто-то объяснить, в чём профит компилировать ядро clang'ом?

подтвержаю.

юзаю gcc для arm/aarch64

Наверное в том, что Clang лучше или может стать лучше gcc в ближайшее время. Например сообщения об ошибках и предупреждения в Clang изначально лучше, чем в gcc. Ну и кроме того за Clang стоят корпорации, без которых Linux - ничто.

Которые не делятся исходниками своих патченных компиляторов. Вот она ваша фейковая швабодка.

#pragma fat

Clang не зря в названии имеет Cl, намёк на cl.exe!

Которые не делятся исходниками своих патченных компиляторов. Вот она ваша фейковая швабодка.

Напиши сам или заплати деньги и открой. Они тебе ничем не обязаны. Именно такие ответы я обычно получаю от линуксоидов здесь на ЛОР-е, когда говорю, что мне в Linux чего-то не хватает. Например нормального remote desktop. Теперь ты видишь у кого действительно «швабодка»?

Ну так вали на ФриБЗДи, там тебе и ядро шлангом собирается, и ремот дексктоп заработает и брат выздоровеет.

Это типичное EEE, только от Столмана и Ко. Но злой по прежнему майкрософт, ага.

Правильно, их как раз таки никто ничем не обязывает. Потому что «швабодка» BSD-like лицензий на самом деле и не швабодка. Она даёт разработчику свободу зажопить код, тем самым нарушая свободу юзеров.

Ок, а какая мотивация для разработчиков Linux поддерживать компилятор под лицензией, которая поощряет закрытие наработок, когда есть свободный GCC?

Ничего такого лицензия Clang не поощряет. А мотивация вполне разумная - отвязка от GCC специфичных нестандартных костылей и возможность сборки ядра более чем одним компилятором.

Открытый код остаётся открытым и в BSD-like лицензиях. Только не начинай этот спор в миллион первый раз. Надоело уже доказывать очевидное.

Что за EEE?

Так я не начинаю. Я просто риторически напоминаю, что некоторым разработчикам ядра тоже надоело спорить, они просто забивают на clang, в том числе и на принятие патчей. Было несколько обсуждений в LKML, жаль, не могу быстро найти ссылки.

А зачем? Если gcc и есть стандарт де-факто для разработки ядра, и всегда им был. Компилятор - это тоже инструмент. Как и специфические расширения компилятора.

Что другие компиляторы могут предложить взамен? Не ухудшится ли производительность или читабельность кода, если отказываться от существующих решений?

Что за EEE?

https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish

Суть претензий в том, что GCC <> C поэтому затачивание под GCC это отказ от стандартов в пользу продвижения GCC.

Как же забивают, когда полно коммитов с указанием Clang в описании? Не удивлюсь, если через год или два компиляция ядра при помощи Clang будет поддерживаться официально.

Одни забивают, другие поддерживают. Демократия.

Ну, например, затем, чтобы не держать два компилятора в системах, где большинство другого софта компилируется Clang-ом. Или для поддержки платформ, которые не поддерживаются или плохо поддерживаются GCC. GCC - вовсе не стандарт и на нём свет клином не сошёлся.

gcc и есть стандарт де-факто для разработки ядра, и всегда им был.

А IE4 был стандартом де-факто для веба. Тем не менее IE-specific код - плохой код. И также Chrome-specific код - плохой код. А хороший код - W3C код.

Также и GCC-specific код - плохой код, а хороший код - С11 код.