LINUX.ORG.RU

Linux перейдёт на использование стандарта C11 в версии 5.18 или одной из следующих

 , ,


1

1

Во время обсуждения набора патчей, связанных с исправлением уязвимостей класса Spectre в коде для работы со связанными списками, стало ясно, что проблему удалось бы решить более изящно, если бы в ядро допускался код, использующий стандарт старше C89. Сейчас код в ядре должен соответствовать С89 (с GNU расширениями) на основе спецификации, сформированной ещё в 1989 году. Связанная со Spectre проблема была в том, что для перебора элементов списка используется макрос. Так как переменная цикла передаётся в этот макрос, то она определяется вне самого цикла и остаётся доступна после цикла. Использование более новых стандартов языка C позволит определять переменные для цикла прямо в блоке for.

В связи с этим, Линус Торвальдс предложил попробовать перейти в ядре 5.18 на стандарт C99, который был опубликован в 1999 году, на что получил встречное предложение перейти сразу на C11. При проверке сборки в GCC и Clang с новым стандартом проблем пока не возникло и, если при более тщательном тестировании ситуация не изменится, в сборочных скриптах ядра 5.18 опция --std=gnu89 будет заменена на --std=gnu11 -Wno-shift-negative-value.

В случае неудачи, переход будет отложен на один из следующих выпусков.

>>> Подробности



Проверено: xaizek ()
Последнее исправление: maxcom (всего исправлений: 5)

Ответ на: комментарий от firkax

Переменные это не обязательно стек. Разве локализация переменных в коде не позволит компилятору более эффективно использовать регистровую память? Да и читать попроще

cobold ★★★★★
()
Последнее исправление: cobold (всего исправлений: 1)
Ответ на: комментарий от cobold

Я в курсе, и уже писал: Linux перейдёт на использование стандарта C11 в версии 5.18 или одной из следующих (комментарий)

Локализацию переменных оптимизирующий компилятор может узнать из того, где они по факту используются (трассируя потоки данных), подсказки в виде скопов ему для этого не нужны.

Читать проще когда алгоритм не перемешан с объявлениями.

firkax ★★★★★
()
Ответ на: комментарий от black_cat

И, почему нельзя было обойтись от GNU extensions для gcc? Неужели нельзя писать ОС на чистом C?

Чистого Си не существует, есть много равноправных диалектов. Название «Си» - никому не принадлежит и не может быть централизовано. Диалекты gnuXX наверно самые популярные.

C89

Там нет 64-битных типов например.

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

anonymous
()
Ответ на: комментарий от firkax

Проблема 64-битных типов - проблема стандартной библиотеки, которую можно расширить, добавив их. Если я правильно понимаю, можно таким образом сохранить совместимость с стандартом C89.

Без inline функций и большинства нововведений новых стандартов легко можно обойтись, а вот стандартную библиотеку, конечно, нужно расширять.

black_cat
()
Ответ на: комментарий от anonymous

Тебя папа с мамой делали совершенно ретроградским, несовременным и немодным способом которому сотни миллионов, если не миллиард лет

Ты сравнимаешь старую технологию, которой миллиарды лет, с технологией, которой лет 20. Это как призывать пользоваться первым айфоном, «потому что он проверен временем». Нифига оно не проверено временем, а как будет проверено — так будет проверено.

byko3y ★★★★
()
Ответ на: комментарий от Psilocybe

Вообще-то объявление переменных - это та самая избыточная информация, благодоря которой компилятор находит определенный класс ошибок

Не объявление переменных, а объявление типов. Представь, что сможет найти компилятор, если в паскале сделать 100% объявлений переменных бестиповыми? А если тебе нужны только типы, то объявляй типы там, где они что-то значат, а не обособлено в начале функции.

byko3y ★★★★
()
Ответ на: комментарий от firkax

Во-первых, «локальные переменные цикла» это на самом деле локальные переменные функции (технически), просто с искусственно ограниченной областью видимости.

Это уже зависит от оптимизаций компилятора. В любом случае возможность указать, что эта переменная за пределами цикла не нужна уже хорошо. Множество ошибок будет выявлено уже на этапе компиляции.

AVL2 ★★★★★
()
Ответ на: комментарий от black_cat

Причём тут библиотека? В С89 нету способа задать целочисленную переменную гарантированно не меньше 64-бит, которую потом можно использовать в обычной арифметике. Через костыли с struct u64 { uint32 low, high; } и add64(&a,&b) вместо a+b конечно можно, но это не то что надо.

firkax ★★★★★
()
Ответ на: комментарий от X512

А в чем трудность? Если можно, чуть попроще, я в оптимизирующих компиляторах очень сильно не эксперт.

anonymous
()
Ответ на: комментарий от byko3y

Но ведь был и момент когда этой «старой технологии» и было двадцать лет. И она победила. Твой аргумент вполне можно развернуть в обратную сторону - то что другие технологии новее совершенно не означает что они лучше и на них нужно переходить. Пока не видно особых преимуществ от внедрения этого «нового», а вот проблемы вполне способны всплыть. Незачем ремонтировать то что не сломалось (это вольный перевод японской поговорки), не надо внедрять новое только потому что оно «новое». Оно еще сырое и непроверенное, ему даже двадцати лет нет).

anonymous
()
Ответ на: комментарий от byko3y

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

crypt ★★★★★
()
Ответ на: комментарий от anonymous

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

А уж тем более распараллелить… Вон, в соседней новости линкер на двадцатых плюсах написали, работает, говорят, быстро.

anonymous
()

Считаю, что время попробовать Nim.

le_legioner ★★
()
Ответ на: комментарий от firkax

По той же причине избегаю конструкций вида int a = 1; - пишу int a; и уже под всеми переменными a = 1;

Какая чушь. Впрочем, каждый сходит с ума по своему

anonymous
()
Ответ на: комментарий от anonymous

В си ты, имея опыт работы, не один конечно год, значительно лучше можешь предсказать поведение программы чем в крестах. В крестах ты имеешь большинство сишных проблем, но добавляются еще и свои, специфические. Да, на си писать труднее, за памятью действительно надо следить, но когда ты это делаешь, то получается действительно рабочая, быстрая и при соблюдении минимальных правил написания кода понятная вещь. Когда, польстившись на простоту, человек пишет подобные вещи на крестах, получается глючное и непредсказуемое поделие в коде которого даже авторы спустя пару лет обычно не могут разобраться, а уж предсказать поведение обычно не могут даже в момент выхода. Если же на них писать внимательно, вдумчиво и вручную разруливая все что можно, то выигрыша во времени не будет, по крайней мере большого.

anonymous
()
Ответ на: комментарий от thesis

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

zabbal ★★★★★
()
Ответ на: комментарий от zabbal

В гробу я видал этих «энтузиастов». Они в большинстве своем имеют пять мелких коммитов на гите за десять лет, а остальное время «кодят на форумах». Вреда от них зачастую больше чем пользы. А уж «энтузиасты» в си это вообще отдельная песня.

anonymous
()
Ответ на: комментарий от cobold

А тебе то какой минус?

Покупаешь свежую машину с хорошим дисконтом

мне есть на что еще потратить деньги, очевидно.

crypt ★★★★★
()
Ответ на: комментарий от anonymous

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

… уровня hello world. Для чего-то сложнее он не годится.

Человек спросил почему, я ответил. Есть конкретные примеры - llvm, clang, gcc - все на современных плюсах. Msvc тоже на двадцатых с consteval.

А то, со написал ты - какая-то феерическая хрень не имеющая ничего общего с реальностью.

anonymous
()
Ответ на: комментарий от firkax

Вот послушайте голос со стороны. Я же не владею СИ и не писал кода столь много что бы об этом рассуждать. Не делайте этого. Оставайтесь на С89. Ваш макрос можно переделать кучей способов но вы решили менять стандарт на стандарт узаканивающий костыли. И вы уже это сделали. Что же, всё неминуемо гибнет. Таковы законы эволюции. Не нужно быть хорошим программистом что бы понять это. Не зря люди занимаются специальными олимпиадами сокращая количество строк кода. Стандарт должен быть очень коротким для Си. В этом приятная специфика. К совершенству легче прийти сокращая стандарт, чем его дописывая. Сложную систему сложнее сбалансировать. Ну как ещё сказать. Я конечно не имею права судить.

baaba ★★★
()
Последнее исправление: baaba (всего исправлений: 2)
Ответ на: комментарий от anonymous

уровня hello world. Для чего-то сложнее он не годится

Очевидно ты как раз «энтузиаст». Если ты не знаешь для чего и как используется си, или просто не умеешь в си, то это не значит что он пригоден только для «hello world».

anonymous
()
Ответ на: комментарий от baaba

Что ты несёшь? Какой макрос? Ты хоть понимаешь сообщение на которое отвечаешь, если не понимаешь, зачем ты это пишешь?

anonymous
()
Ответ на: комментарий от anonymous

А в чем трудность? Если можно, чуть попроще, я в оптимизирующих компиляторах очень сильно не эксперт.

На С++ можно предотвратить целый класс ошибок, которые возможны в С.

https://devblogs.microsoft.com/cppblog/how-we-used-cpp20-to-eliminate-an-entire-class-of-runtime-bugs/

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

Ты только не забудь что на с++ можно налепить целые классы ошибок в принципе невозможных в с. Иначе говоря, ты заменяешь одни ошибки другими, причем выигрыш не очевиден. Единственный плюс который я вижу у с++ это возможность более быстрой и более дешевой разработки, но достигается это ценой сильного падения качества кода, по крайней мере в проектах такого типа.

anonymous
()
Ответ на: комментарий от anonymous

Педеруст ещё недостаточно протух.

Hertz ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

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

anonymous
()
Ответ на: комментарий от anonymous

за памятью действительно надо следить, но когда ты это делаешь

То постепенно сходишь с ума, число ошибок растет сначала линейно, а потом квадратично. Посмотри как кончил автор sendmail, который писал ее 30 лет. А по нынешним меркам, это фигня, а не программа.

anonymous
()
Ответ на: комментарий от Croco

VLA

Тоже подумал про них, но как раз в C11 их (полу)выкинули. Т. е. признали необязательными.

Так что да, уточнение к ответу на исходное сообщение: C11 действительно может быть проще реализовать, чем C99.

anonymous
()
Ответ на: комментарий от anonymous

Очевидно, «хочется» нормального стандарта, которого все должны придерживаться.

P.S. я слышал в bsd системах с эти лучше.

black_cat
()
Ответ на: комментарий от black_cat

Не парься - он сильно преувеличивает.

anonymous
()
Ответ на: комментарий от black_cat

Очевидно, «хочется» нормального стандарта, которого все должны придерживаться.

Мне очевидно только то, что тебе хочется странного.

Ты пишешь на си или программист ядра линукс? Если пользователь, то какая тебе разница какого стандарта они придерживаются?

anonymous
()
Ответ на: комментарий от LongLiveUbuntu

Не enum, а проверку в compile-time того, что переданы правильные аргументы в функцию, которая парсит строку.

Фактически, это компилятор printf-языка, который проверяет валидность программы на этапе компиляции С++ программы.

anonymous
()
Ответ на: комментарий от black_cat

Эрик курил траву, бухал, сидел на крэке и 30 лет жахал в булки другого unix хакера, который был ядерный девелопер bsd и тоже писал на С, как Эрик свой sendmail. Потом они поженились и живут счастливо.

anonymous
()
Ответ на: комментарий от firkax

Переменная не обязана храниться в стеке. Она может храниться (после оптимизации) в регистре (и больше нигде).

Если связывать исходный код с получаемым кодом на ассемблере, то объявление переменной в таком случае можно интерпретировать как указание на то, для чего в ассемблерном коде, соответствующем области видимости переменной, используется выделенный для неё регистр.

Вообще, не думаю, что будет хорошей идеей рассматривать C как кросс-платформенный макроассемблер.

anonymous
()
Ответ на: комментарий от anonymous

Ещё один не-читатель треда: Linux перейдёт на использование стандарта C11 в версии 5.18 или одной из следующих (комментарий)

объявление переменной в таком случае можно интерпретировать как указание на то, для чего в ассемблерном коде, соответствующем области видимости переменной

Нет, не области видимости, а области использования. Область использования конечно не может быть больше области видимости, но это уже дело программиста. Сама же область видимости, в хорошем оптимизирующем компиляторе, не влияет на кодогенерацию НИКАК.

, используется выделенный для неё регистр.

И не регистр, а виртуальное lvalue. Оно может плавать между разными регистрами и стеком по ходу дела, главное чтобы нигде одновременно с другой активной переменной не оказалось.

firkax ★★★★★
()
Ответ на: комментарий от firkax

виртуальное lvalue

Сам придумал?

anonymous
()
Ответ на: комментарий от firkax

Конечно, выделение памяти с областями видимости не связано. Оно вообще может проходить в начале выполнения функции один раз, если компилятор сможет вычислить размер локальных переменных. Да, компилятор может определить, что переменная больше не используется, и без областей видимости.

Вообще, область видимости ограничивает использование имени, а не памяти. Имени, которого в получаемом машинном коде может и быть, особенно после работы линковщика.

Вложенные области видимости можно вынести в отдельные функции (причём сделав их inline), но тогда может возникнуть необходимость в передачи большего числа параметров (все переменные внешней области видимости, которые использовались во внутренней).

То есть, твоё утверждение «Объявления локальных переменных это считай описатель внутреннего стека функции» (Linux перейдёт на использование стандарта C11 в версии 5.18 или одной из следующих (комментарий)) тобой же и отвергается.

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

А почему, ты считаешь, что базовым видом алгоритма является получаемый компилятором ассемблерный (или машинный) код, а не исходный, который пишется и читается программистом?

anonymous
()
Ответ на: комментарий от firkax

главное чтобы нигде одновременно с другой активной переменной не оказалось.

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.