The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"В ядре Linux 5.18 планируют разрешить использование стандарта языка Си C11"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В ядре Linux 5.18 планируют разрешить использование стандарта языка Си C11"  +/
Сообщение от opennews (??), 25-Фев-22, 18:02 
В процессе обсуждения набора патчей с исправлением связанных с уязвимостями класса Spectre проблем в коде  для работы со связанными списками, стало ясно, что проблему удалось бы решить более изящно, если бы в ядро допускался код на языке Си, соответствующий более новой версии стандарта.  В настоящее время добавляемый ядро код должен соответствовать спецификации ANSI C (С89), сформированной ещё в 1989 году...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56760

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +26 +/
Сообщение от Аноним (1), 25-Фев-22, 18:02 
> Си C11

ну вот наконец си си кэпвелл и вышел из комы

Ответить | Правка | Наверх | Cообщить модератору

24. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Аноним (-), 25-Фев-22, 19:38 
Алилуя, давно пора. А, кэпвеллу дивный новый мир не понравится, пичалька.
Ответить | Правка | Наверх | Cообщить модератору

79. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –3 +/
Сообщение от Аноним (-), 26-Фев-22, 13:24 
Это 152400-я серия Санта-Барбары? Меня удивляло то, что вполне респектабельные уважаемые театральные актёры России тащились от этого третьесортного сериала масштаба одного штата, Калифорния кажется. Потом я узнал что этот сериал в даже своём штате имел низкие рейтинги. Оказывается мои знакомые американцы вообще не знали про существование этого сериала. 1990-е российские федеральные телеканалы закупали третьесортные сериалы и скармливали их собственному населению. "Богатые тоже плачут" это вообще сериал 1970-х гг. Копец! Мексиканцы удивлены.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

106. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +5 +/
Сообщение от Аноним (106), 27-Фев-22, 13:02 
Понять бы только, с чего тебя так бомбануло.
Ответить | Правка | Наверх | Cообщить модератору

109. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 27-Фев-22, 13:28 
> Понять бы только, с чего тебя так бомбануло.

"Анонимов тоже бомбит!" -  высокорейтинговый сериал опеннета, 1996-2022 год

Ответить | Правка | Наверх | Cообщить модератору

125. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 01-Мрт-22, 23:02 
За отсутствием сериалов марвела и диснея - сойдет. Экранизуйте.
Ответить | Правка | Наверх | Cообщить модератору

110. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Ан (??), 27-Фев-22, 19:18 
Весна же. Чуть раньше календарной в этом году.
Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

107. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Аноним (107), 27-Фев-22, 13:06 
Почему "тащились"? Очень просто - потому что другого *ничего* не было. На безрыбье, как говориться...
Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

120. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Crazy Alex (ok), 28-Фев-22, 20:30 
Ну логично, совковому зрителю вообще можно было что угодно скормить, да и потом, насколько я понимаю, 99% шоу были передраны или перекуплены с Запада. И брали, понятно, что попроще сделать да подешевле купить
Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

2. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (2), 25-Фев-22, 18:06 
> настоящее время добавляемый ядро код должен соответствовать спецификации ANSI C (С89), сформированной ещё в 1989 году.

Зачем использовать такую старую спецификацию, всем смысл?

Ответить | Правка | Наверх | Cообщить модератору

4. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +5 +/
Сообщение от Аноним (4), 25-Фев-22, 18:10 
А в чём ранее был смысл использовать более новую?
Ответить | Правка | Наверх | Cообщить модератору

8. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +8 +/
Сообщение от Аноним (2), 25-Фев-22, 18:23 
Да хотябы вот C11 "Интерфейсы для проверки границ массива"
Ответить | Правка | Наверх | Cообщить модератору

116. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от adolfus (ok), 28-Фев-22, 11:47 
Самый лучший интерфейс для этого -- межушный.
Использование третьей версии языка (9899-2011) в ядре ради его безопасных конструкций, в частности это for с объявлениями в expr1. Также с С11 есть атомарные фундаментальные типы.
Ответить | Правка | Наверх | Cообщить модератору

27. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +8 +/
Сообщение от Аноним (-), 25-Фев-22, 19:48 
> А в чём ранее был смысл использовать более новую?

1) Нормальные типы данных. Простите, int - это очень неконкретно. Может быть 16 битов, а может и 64. А теперь попробуйте на этом математику сделать без багов и кроссплатформенно, ню-ню. Даже у большинства аксакалов код обгаживается на этом только в путь.
2) Стандартизация того что есть true и false в булеанах, устаканеная работа с этим всем, в частности, assignment чего либо кроме нуля ведет к assignment единицы и рассмотрению как true, в самопальных реализациях возможны самые разные варианты. Что добавляет багов и глюков, а кодер не знает чего ожидать.
3) Вариадики, особенно макросы, годная штука. Вариадик функции в ядро тащить не стоит, пожалуй, но макросы можно делать и относительно беззубыми.
4) Static Assert есть. На более ранних сях аналог сделать можно - но нельзя получить красивое сообщение об ошибке стандартными средствами если условие провалилось.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

33. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –2 +/
Сообщение от pashev.me (?), 25-Фев-22, 20:48 
Ты сейчас с кем говорил?

Давай в контексте ядра Линукс.

Ответить | Правка | Наверх | Cообщить модератору

36. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +2 +/
Сообщение от Аноним (-), 25-Фев-22, 21:01 
У них большая часть этого есть. Только наколенно.
Ответить | Правка | Наверх | Cообщить модератору

46. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –7 +/
Сообщение от Аноним (46), 25-Фев-22, 22:12 
Любишь все блестящее и бесполезное?
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

63. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +4 +/
Сообщение от Аноним (63), 26-Фев-22, 02:32 
Любишь тупые баги в математике, с overrun'ами/negative index deref и вообще уродский код? Я видел достаточно такого кода чтобы научиться его ненавидеть :)

Линуксоиды так то подобие C99/11 и из 89 сделали себе. И более вменяемые типы, и статик ассерты, и прочие плюшки. Только это очень уж педальненько было.

Ответить | Правка | Наверх | Cообщить модератору

81. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от tty0 (?), 26-Фев-22, 13:39 
Вроде пишется по конкретный компилятор? А про остальные портируется (с ответственностью на тех, кто портирует). Или я чего то не понимаю? Зачем тащить скраб, когда он не нужен? Зачем синтаксический сахар, когда он вносит больше неопределённости?
Ответить | Правка | Наверх | Cообщить модератору

85. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +2 +/
Сообщение от Аноним (-), 26-Фев-22, 16:07 
> Вроде пишется по конкретный компилятор?

Оно как бы так стало не потому что так всем очень нравится, а потому что в стандарте НЕТ некоторых вещей требующихся для написания ядер, бутлоадеров, фирмварей и прочего. Номинально есть freestanding, но он только о том что кто должен и не должен реализовывать. А про то как разместить вот эту функцию в вон той секции, и как кастомно компоновать адресацию, лэйаут памяти и проч - там ничего нет. И тут оказывается что вот эта хрень - компилер специфична. И вы либо вообще обламываетесь, либо кодите под кого-то конкретного. Используя extended фишки которых в стандартах НЕТ.

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

> А про остальные портируется (с ответственностью на тех, кто портирует).
> Или я чего то не понимаю? Зачем тащить скраб, когда он не нужен?

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

> Зачем синтаксический сахар, когда он вносит больше неопределённости?

Никакой неопределенности оно не вносит. А делать велосипед самому из ржавых труб может и задолбать, особенно если можно и получше чем это. Самолично хреначить детект истинных размеров типов и из этого крафтить потребные exact width типы, обвесив столь же самопальными квазиассертами из гамна и палок вида #define assert(cond, why) typedef char why[cond ? 1 : -1] - это имнено оно! И даже еррор при обломе - кривой. А в C11 это все есть сразу и не через зад.

Ответить | Правка | Наверх | Cообщить модератору

76. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от _kp (ok), 26-Фев-22, 12:49 
>> А в чём ранее был смысл использовать более новую?

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

А то, помню ржали над одной поделкой где bool складывали, и это ж работало.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

86. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Аноним (-), 26-Фев-22, 16:17 
> Нативная поддержка типов, и bool в частности, это не только отсутствие необходимости
> включать заголовочные файлы, а то что сам компилятор о них знает,
> как проверять и оптимизировать.

1) Вообще-то включать хидеры по стандарту для этого надо. С определениями этсамого.
2) И ващет складывать бульоны так никто и не запрещает. Они внутрях мапятся в какой-нибудь integer. НО КОЕ ЧТО ВСЕ ЖЕ ОТЛИЧАЕТСЯ.

Есть простой пример:
uint8_t boolvalue = 0; // false, типа.
...
boolvalue = 256; // ...но готовы ли вы к тому что вот так - тоже false?

А вот если это boolean, любое присвоение которое не ноль по стандарту рубится до 1. И соответственно, вон то - тоже true. Ну, если вы не 0 хотели, очевидно, это было не про false?!

Во всяком случае это - четко определенное и довольно логичное поведение, а не implementation defined (как в компилере, так и в самопальных макро) с более 9000 разных вариантов как это вообще может быть - и таким же колиеством багов, когда идеи кодеров и компилеров о том как это считается не совпали.

> А то, помню ржали над одной поделкой где bool складывали, и это ж работало.

Яваскриптеры наверное. У них такое норма жизни, вплоть до того что +1 и ++ может довольно разные вещи означать =)

Ответить | Правка | Наверх | Cообщить модератору

105. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от . (?), 27-Фев-22, 12:11 
> 1) Нормальные типы данных. Простите, int - это очень неконкретно. Может быть 16 битов, а может и 64. А теперь попробуйте на этом математику сделать без багов и кроссплатформенно, ню-ню. Даже у большинства аксакалов код обгаживается на этом только в путь.

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

остальное не тянет на обсуждение - хотелки.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

126. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 01-Мрт-22, 23:18 
> у каждого типа есть гарантированный низ размерности.

По факту большая часть кода не готова к тому что int будет 16 бит, равно как и char. По стандарту так можно было.

> использование фиксированных типов ухудшает портабельность,

Если кто не снялся с тормоза за 22 года, это его проблемы, имхо. Это все умеет даже tcc и sdcc какой-нибудь, под недоношеных 8-биток. Если у кого-то платформа большее дно чем ЭТО, сие его проблемы.

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

Неа. Если я сказал uint8_t - он 8 битов и я могу на это уповать. И либо оно так, либо это не компилится. Второе - проблемы дохлой платформы, а не мои. Вы или соответствуете пререквизитам, или я вам ничего и не обещал. Да, C99 compiler везде заявлен как build dep. А абстрактным unsigned int сами странные баги собирайте.

> остальное не тянет на обсуждение - хотелки.

А почему бы мне не хотеть пользоваться нормальными тулзами? Штатные типы си это жесть, как и тот миндфак который он делает с integer promotions

Ответить | Правка | Наверх | Cообщить модератору

137. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Neon (??), 16-Мрт-22, 01:52 
Как определенность в размере типов ухудшает портабельность ?!
Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

119. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Аноним (119), 28-Фев-22, 16:11 
Лишь бы C++ не использовать.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

53. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +4 +/
Сообщение от Аноним (53), 25-Фев-22, 23:29 
>А в чём ранее был смысл использовать более новую?

Да вот только за отсутствие возможности написать for (int i=0; i<n; i++), С89 следовало бы давно выжечь.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

64. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Аноним (-), 26-Фев-22, 02:36 
И это тоже. Полно случаев когда i объявили, сделали большой кус, сто раз забыли как объявили, лоханулись по тупому, ...

А можешь объяснить пойнт (signed) int в данной конструкции? А то вот такие вот чудеса очень любят уходить в минус, потому что могут, особенно если оно из параметра caller'а считается... и потом получается интересно. Потому что (signed) с большим минусом < n так то довольно долго выполняеться может... а если это еще и индекс в массиве был, вам точно амба

Ответить | Правка | Наверх | Cообщить модератору

82. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от tty0 (?), 26-Фев-22, 13:44 
Говорить не запретишь, но в ядре... Хотя молодость
Ответить | Правка | Наверх | Cообщить модератору

138. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от memer228 (?), 17-Май-22, 00:07 
Ну стандарт языка считает, что уйти в минус оно не может, а в случае с unsigned приходится гарантировать правильное переполнение, это может стоить не так мало (вот пример: https://youtu.be/yG1OZ69H_-o?t=2357 — наверное, правильным фиксом было бы использование size_t, но они под настолько экзотические платформы делают вид, что собираются, что до сих пор не сделали ничего).
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

16. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +11 +/
Сообщение от _kp (ok), 25-Фев-22, 18:54 
Изначально смысл был что бы собирать ядро под платформы где компиляторы частично поддерживают стандарты, а таких и сейчас как грязи, не поддерживающих полностью  не только C11, но и gnu99.
Далее было лень, наверное, обновлять требования к компиляторам.

Но, это не могло длиться вечно, и наконец то обновляются. Молодцы.


Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

23. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +2 +/
Сообщение от пох. (?), 25-Фев-22, 19:31 
Никогда не было, ядро никогда ничем кроме gcc нормально не собиралось. Даже для llvm, старавшегося сохранить совместимость, пришлось в куче мест править.
Изначально был смысл чтобы собирать ядро под платформы, для которых нет и не факт что будет когда-нибудь моднейшая версия gcc. Скажи спасибо если есть кое-как когда-то портированный вендором 2.7.2

Да, внезапно на таких платформах тоже мог кому-то понадобиться линукс.

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

Ответить | Правка | Наверх | Cообщить модератору

28. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –5 +/
Сообщение от Аноним (-), 25-Фев-22, 19:53 
> Скажи спасибо если есть кое-как когда-то портированный вендором 2.7.2

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

> Да, внезапно на таких платформах тоже мог кому-то понадобиться линукс.

Пусть юзают ядра современные компилеру, например :)

> незачем особо и стараться.

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

TL;DR: никто не будет делать из ваших проблем свои. Абыдна, да?
  

Ответить | Правка | Наверх | Cообщить модератору

49. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от пох. (?), 25-Фев-22, 23:16 
то есть л@п4оподелка должна оставаться на тех двух платформах, которые одобрила ibm?
Ну ок, все правильно, зачем ее еще куда-то портировать. Профита ibm с этого никакого, и другим платиновым тоже, ведь там поди и винды-то нет.

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

Нет, трахаться с портированием версии 1.0.102 "современной компилеру" никто не будет, это мартышкин труд.
Поищут просто менее хипстерскую систему для своей платформы, которую можно собирать более общедоступными компиляторами.

Ответить | Правка | Наверх | Cообщить модератору

65. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 02:44 
То-есть актуальное ядро живет на актуальных платформах, на которые комьюнити или вендор не забили. Т.е. пока есть те кто майнтайнит это. Они не как бзды, помойкой для подачек быть не собираются. Код или майнтайнится - или сперва в staging, потом если всем пофиг, труп считается трупом и уносится в морг. Правила просты.

И мне плевать что там с платформами на 2.7.каком-то gcc, я меньше 7 уже сто лет не видел.

Не будут трахаться с портированием? Тем хуже для них, я тоже не собираюсь пользовать окаменелый кал без нормальной диагностики, статического анализа и оптимизаций с кучей ископаемых багов. Поможет платформе помереть быстрей, куда и дорога. Это не мои проблемы - я просто другую возьму. А что эти некромансеры поищут мне не интересно. Как показала практика, их клиенты на раз поищут менее @#$%нутую фирму с которой проще иметь дело в таком случае. В каких-то совсем нишевых случаях может и не поищут, но это будут сильно нишевые системы. И даже им постепенно амба наступает, я так то помог вынести кой кому окаменелый куникс на который все забили так то. Не, он им не нужен был, просто манагерье 100500 лет взяло его потому что круто. Реалтайм им был нафиг не.

Ответить | Правка | Наверх | Cообщить модератору

51. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от _kp (ok), 25-Фев-22, 23:23 
> Никогда не было, ядро никогда ничем кроме gcc нормально не собиралось.

Не под всякую архитектуру и gcc актуальной версии есть.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

54. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (53), 25-Фев-22, 23:34 
>Скажи спасибо если есть кое-как когда-то портированный вендором 2.7.2

А дальше ядра-то что? GLibc нужен C99. Думаю, Musl'у тоже не менее.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

58. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от пох. (?), 26-Фев-22, 00:06 
а дальше можно хотя бы пытаться собрать gcc штатным образом.

> GLibc нужен C99.

glibc до недавнего времени был кросплатформенным. То есть усилия по портированию минимальны, можно взять тот что попроще. А вот портировать кросс-компилятор (потому что native нет и быть для этой архитектуры не может) без работающей системы - это так себе развлечение.

Ответить | Правка | Наверх | Cообщить модератору

87. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 16:28 
> а дальше можно хотя бы пытаться собрать gcc штатным образом.

Пох вам расскажет как сделать все дерьмово и сложно. Но есть и способы лучше.

1) Берем нормальный компилер на своем хосте, типа свежего гцц из своего дистро. Не надо быть при этом как пох, если вашему дистро более 5 лет, выньте скелетов из шкафа уже и поставьте что-то менее архаичное, нормальный компилер этого уж точно стоит. Им собираем себе кроссовый gcc, хоть самый свежий. Это быстро и если вы не используете на хосте окаменелый кал или прочие маздаи - довольно просто к тому же. GCC обычно может сам себя собрать минуя фазу бутстрапа, так что с места в карьер непохабный компилер под таргет.

2) А вот этим уже можно собрать себе ядро, бутлоадеры и проч как белый человек.

> native нет и быть для этой архитектуры не может) без работающей
> системы - это так себе развлечение.

Если архитектура в gcc поддерживается то самому кросс собрать - ну ваще не напряг. А если не поддерживается - какой задницей вы думали когда это железо вообще брали? Будете вместо вендора этого кала компилер кодить вместо реализации своей задачи? Ну, удачного бизнеса с таким подходом, можете и заяву о банкротстве заполнить заранее, пригодится: если из чужих проблем делать свои, бизнес долго не протянет.

Ответить | Правка | Наверх | Cообщить модератору

84. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от AKTEON (?), 26-Фев-22, 15:31 
В  поддерживаемом компилляторе , конечно же
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –8 +/
Сообщение от DEF (?), 25-Фев-22, 18:08 
А почему не C17, который более модерновый?
Ответить | Правка | Наверх | Cообщить модератору

5. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +2 +/
Сообщение от макпыф (ok), 25-Фев-22, 18:15 
Написанно же:

> Рассматривалась возможность и использования стандарта C17, но в этом случае пришлось бы повышать минимально поддерживаемую версию GCC

Ответить | Правка | Наверх | Cообщить модератору

10. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +3 +/
Сообщение от Аноним (10), 25-Фев-22, 18:27 
>пришлось бы повышать минимально поддерживаемую версию GCC

И в чем проблема? Некрофилы всякие все равно сидят на LTS.

Ответить | Правка | Наверх | Cообщить модератору

17. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +3 +/
Сообщение от _kp (ok), 25-Фев-22, 18:57 
>>пришлось бы повышать минимально поддерживаемую версию GCC
> И в чем проблема? Некрофилы всякие все равно сидят на LTS.

Это для intel и arm всё хорошо с компиляторами, но есть и менее популярные платформы, под которые собирают ядро, и там явно распространены компиляторы не осилившие поддержку _полностью_ с17.
С заботой о неосиляторах.

Ответить | Правка | Наверх | Cообщить модератору

39. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –2 +/
Сообщение от Самокатофил (?), 25-Фев-22, 21:12 
о как... а выше тролли говорили про "никто не будет решать проблемы неосиляторов, абидна да".
Ответить | Правка | Наверх | Cообщить модератору

70. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Аноньимъ (ok), 26-Фев-22, 08:06 
Интересно что за платформы такие.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

102. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Дон Педро (?), 26-Фев-22, 22:00 
Отвлекись от х86 и найдешь кучу таких платфром.
Ответить | Правка | Наверх | Cообщить модератору

131. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (131), 02-Мрт-22, 10:27 
...которые благополучно сдохли в лучшем случае ещё в нулевых
Ответить | Правка | Наверх | Cообщить модератору

6. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +2 +/
Сообщение от Валерий (??), 25-Фев-22, 18:15 
Написано ж почему

Рассматривалась возможность и использования стандарта C17, но в этом случае пришлось бы повышать минимально поддерживаемую версию GCC

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

91. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 16:40 
И, главное: назовите вашу любимую фичу C17 которой нет в C11? А, погодите, 17 это такая слегка исправленная версия 11, в которой для разработке кернелов нет почти ничего полезного? Нну...

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

Ответить | Правка | Наверх | Cообщить модератору

7. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от устаревший си (?), 25-Фев-22, 18:15 
Читать надо внимательней.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

117. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от adolfus (ok), 28-Фев-22, 12:05 
С17 содержит практиечски только косметические изменения, не затрагивая по существу ничего в самом языке.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

20. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +3 +/
Сообщение от Аноним (20), 25-Фев-22, 19:16 
> Линус Торвальдс согласился с идеей реализации поддержки более новых спецификаций

я более довольный

Ответить | Правка | Наверх | Cообщить модератору

22. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (22), 25-Фев-22, 19:19 
Си всё ближн к переходу на быстрый и безопасный язык zig.
Ответить | Правка | Наверх | Cообщить модератору

29. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 25-Фев-22, 19:55 
Забавная штука, лучше хруста на вид. Но пока дико нестабильная, а некоторые тестимониалы дико доставляют. Посмотри про сборку таким манером lwan :)). Тестимониал в виде "...complete failure" все же рановат для серьезного применения.
Ответить | Правка | Наверх | Cообщить модератору

38. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (22), 25-Фев-22, 21:08 
Автор вроде так и говорит надо ждать версию 1.0
Ответить | Правка | Наверх | Cообщить модератору

66. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (-), 26-Фев-22, 02:49 
> Автор вроде так и говорит надо ждать версию 1.0

Хруст это за 10+ лет не смог. Эти имеют более резвые планы? А то моя фамилия, увы, не McLeod чтобы такими вещами не париться :)

Ответить | Правка | Наверх | Cообщить модератору

30. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –3 +/
Сообщение от Аноним (30), 25-Фев-22, 20:02 
>Линус Торвальдс [...] предложил перейти на использование стандарта C11

Почему не 99? Он в разы более подтдерживаемый, чем 11-ый, да и проблем с совместимостью будет меньше (если они будут, конечно)

Ответить | Правка | Наверх | Cообщить модератору

31. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +5 +/
Сообщение от Аноним (-), 25-Фев-22, 20:11 
Так, глядя на часы, сейчас 2022 вообще-то. И если кто за 11 лет не расчехлился, он, наверное, сдох. И нет, ждать по 22 года это все же перебор. Ну и статик ассерты пригодятся. И генерики позволяют в принципе более красивые и менее бажные вещи типа min/max без форсирования типа аргументов на гвозди, например. На макросне так сделать можно, но багов при этом... потому что у препроцессора очень сильно свои идеи как он аргументы жрет, он вам тут не компилер.
Ответить | Правка | Наверх | Cообщить модератору

41. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +2 +/
Сообщение от макпыф (ok), 25-Фев-22, 21:25 
> Почему не 99? Он в разы более подтдерживаемый, чем 11-ый

Минимальные версии компиляторов, нужных ядру, поддерживают 11. Так что ни чего не случиться.

> проблем с совместимостью будет меньше (если они будут, конечно)

Если они будут - не очень большие, C достаточно стабилен.

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

48. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от pashev.me (?), 25-Фев-22, 22:52 
> Он в разы более подтдерживаемый

Что на что делил анонимус?

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

92. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 16:41 
> Что на что делил анонимус?

Плюс бесконечность на NaN :)

Ответить | Правка | Наверх | Cообщить модератору

99. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (99), 26-Фев-22, 18:19 
Насколько я знаю, любая операция с NaN определена и результат равен NaN
Ответить | Правка | Наверх | Cообщить модератору

127. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 01-Мрт-22, 23:20 
> Насколько я знаю, любая операция с NaN определена и результат равен NaN

Э... то-есть наконец можно поделить на ноль? :)

Ответить | Правка | Наверх | Cообщить модератору

50. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от пох. (?), 25-Фев-22, 23:20 
дык кем "в разы поддерживаемый"-то? Проблема с совместимостью с чем-то более ранним чем насквозь гнилой и глючный пятый gcc (хотя бы уже достаточно в свое время залатанный 4.7) давно непроблема - ведро с ними несовместимо и сборку таким "немодным устаревшим дерьмом" не поддерживает.

"зато сообщения об ошибках красивенькие!"(c) кто-то из местных.


Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

55. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Аноним (53), 25-Фев-22, 23:45 
Как будто, внятные и выделенные сообщения об ошибках это недостаток.
Ответить | Правка | Наверх | Cообщить модератору

57. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от пох. (?), 25-Фев-22, 23:55 
Если для этого тебе придется на неведомую х-ню с необычной архитектуркой спортировать gcc - ты как запоешь? А, ну да, ну да, ты же не умеешь кодить...
Ответить | Правка | Наверх | Cообщить модератору

60. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Аноним (53), 26-Фев-22, 00:50 
Один ты тут, ля, умеешь.
Ответить | Правка | Наверх | Cообщить модератору

62. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Аноним (53), 26-Фев-22, 01:00 
Хотел сказать, что чем тупее собщения компилятора, тем легче его портировать? Да, ты-то знаешь толк в кодинге.
Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

67. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 02:51 
> Если для этого тебе придется на неведомую х-ню с необычной архитектуркой спортировать
> gcc - ты как запоешь? А, ну да, ну да, ты же не умеешь кодить...

Ну, наверное, все же не так как при нужде портировать туда еще и хруст :)))

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

77. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от пох. (?), 26-Фев-22, 13:02 
С хрустом пока можно погодить - CoC.md и копипасту gpio драйверка можно первое время на такой платформе не поддерживать.

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

Ответить | Правка | Наверх | Cообщить модератору

93. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 16:44 
Да они пока там на core level своей вундерфафли гамно лаптем хлебают, на каждую новую итерацию патча новые причины и фичи, которые уже почти включены в следующую версию ночного горшка^W билда, так чот вот-вот станет збс. А пока запустите с нашего сайта бэкдор^W майнер^W шелскрипт который вам тут типа-отстроит что-то...
Ответить | Правка | Наверх | Cообщить модератору

88. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (-), 26-Фев-22, 16:32 
> Если для этого тебе придется на неведомую х-ню с необычной архитектуркой спортировать
> gcc - ты как запоешь?

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

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

68. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от leap42 (ok), 26-Фев-22, 05:54 
> Почему не 99?

В нём почти всё было ошибкой, труъ сишники его обычно презирают.

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

89. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 16:34 
> В нём почти всё было ошибкой, труъ сишники его обычно презирают.

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

Ответить | Правка | Наверх | Cообщить модератору

34. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +3 +/
Сообщение от pashev.me (?), 25-Фев-22, 20:52 
Of course, the C standard being the bunch of incompetents they are,
they in the process apparently made left-shifts undefined (rather than
implementation-defined). Christ, they keep on making the same mistakes
over and over. What was the definition of insanity again?

                  Linus

Ответить | Правка | Наверх | Cообщить модератору

45. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Ordu (ok), 25-Фев-22, 22:09 
Hey, some more googling on my part seems to say that somebody saw the
light, and it's likely getting fixed in newer C standard version.

So it was just a mistake, not actual malice. Maybe we can hope that
the tide is turning against the "undefined" crowd that used to rule
the roost in the C standards bodies. Maybe the fundamental security
issues with undefined behavior finally convinced people how bad it
was?

       Он же

Ответить | Правка | Наверх | Cообщить модератору

35. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от minimumlawemail (?), 25-Фев-22, 20:59 
-Wno-shift-negative-value а много где оно есть? В принципе это чистое UB. Неужели проще подавить предупреждение, чем почистить код? Надо бы проверить а то патч сделать.
Ответить | Правка | Наверх | Cообщить модератору

42. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от макпыф (ok), 25-Фев-22, 21:25 
Мб временно
Ответить | Правка | Наверх | Cообщить модератору

40. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +3 +/
Сообщение от Анонимemail (40), 25-Фев-22, 21:15 
https://m.youtube.com/watch?v=QpAhX-gsHMs

Вот теперь заживём.

Ответить | Правка | Наверх | Cообщить модератору

43. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от InuYasha (??), 25-Фев-22, 22:04 
> пришлось бы повышать минимально поддерживаемую версию GCC.

Да уж, не надо задирать без особой надобности.

Ответить | Правка | Наверх | Cообщить модератору

44. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Анонн (?), 25-Фев-22, 22:06 
Дещять лет ждал этого! (с)
Ответить | Правка | Наверх | Cообщить модератору

52. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (53), 25-Фев-22, 23:25 
>предложил перейти в ядре 5.18 на использование стандарта C11, опубликованного в 2011 году.

Шёл 2022 год.

Ответить | Правка | Наверх | Cообщить модератору

56. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от thhh (?), 25-Фев-22, 23:49 
Не шёл, а идёт. Не наркомань.
Ответить | Правка | Наверх | Cообщить модератору

61. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (53), 26-Фев-22, 00:52 
Хорошо, пусть будет так :)
Ответить | Правка | Наверх | Cообщить модератору

113. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (99), 27-Фев-22, 20:02 
> Не шёл, а идёт.

Шёл, идёт, и будет есть.
Сижу на БАД'ax

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

69. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от морошка ягодка такая (?), 26-Фев-22, 06:19 
После слова "изящно" перестал читать
Ответить | Правка | Наверх | Cообщить модератору

90. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 16:35 
> После слова "изящно" перестал читать

Вы не любитель изящных искусств? Поклонник брутала? :)

Ответить | Правка | Наверх | Cообщить модератору

101. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от морошка ягодка такая (?), 26-Фев-22, 20:51 
я вообще слово изящно считаю неприменимым к программированию.

Ответить | Правка | Наверх | Cообщить модератору

108. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (107), 27-Фев-22, 13:16 
Здравствуй, единомышленник! Я так же думаю про слово "морошка".
Ответить | Правка | Наверх | Cообщить модератору

112. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +2 +/
Сообщение от морошка ягодка такая (?), 27-Фев-22, 19:39 
"морошка" не имеет отношение ни к чему кроме ягод. Ты о чём?


Ответить | Правка | Наверх | Cообщить модератору

128. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 01-Мрт-22, 23:22 
> я вообще слово изящно считаю неприменимым к программированию.

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

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

132. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от морошка ягодка такая (?), 03-Мрт-22, 20:40 
> Какой-нибудь Кнут с этим очень крепко не согласится. Но из-за таких считал
> программирование и скатилось в вебмакакинг и джамшутинг.

Извиняюсь, я практик просто

Ответить | Правка | Наверх | Cообщить модератору

71. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (71), 26-Фев-22, 08:29 
> не возникнет непредвиденных проблем

Да уж. В стандарте как в 11 так и в 17, не говоря про предидущие, американским по делому сказано что непредвиденое поведение ДОЛЖНО обрабатываться програмером. И в дополнение к этому выпустили целых два документа про безопасному программированию/кодированию на С и С++. И это ещё не Дейтейлв с Сикордом рекомендоваи, а целый АНСИ коммитет.
Все знают что проблемы возникнуть могутбыть, и что их обрабатывать нужно. Но никто за это зарплаты не получает и не обрабатывает.
Поэтому и баков куча.

Ответить | Правка | Наверх | Cообщить модератору

72. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –3 +/
Сообщение от iPony129412 (?), 26-Фев-22, 09:54 
Луддиты какие-то…
Ответить | Правка | Наверх | Cообщить модератору

73. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Аноним (73), 26-Фев-22, 10:54 
А у FreeBSD какой стандарт си?
Ответить | Правка | Наверх | Cообщить модератору

75. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (-), 26-Фев-22, 12:47 
Не знаю.
Ответить | Правка | Наверх | Cообщить модератору

78. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (78), 26-Фев-22, 13:21 
Почему?
Ответить | Правка | Наверх | Cообщить модератору

94. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 16:46 
> Почему?

Потому что не умеет плюсами опенсорса пользоваться. "Сорцы не читал но осуждаю!"

Ответить | Правка | Наверх | Cообщить модератору

80. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +2 +/
Сообщение от Аноним (-), 26-Фев-22, 13:31 
> А у FreeBSD какой стандарт си?

Доисторический!
Как обычно, безнадежно отстают от перепончатых светочей прогресса, стагнируют и вообще "too slow to innovate" (©ВеликийОпеннетныйОналитег)!


/usr/src/sys/conf/newvers.sh-TYPE="FreeBSD"
/usr/src/sys/conf/newvers.sh:REVISION="12.3"
...
/usr/src/sbin/dumpon/dumpon.c:static void _Noreturn
/usr/src/sbin/ifconfig/ifconfig.c:static _Noreturn void usage(void);
/usr/src/lib/libpmc/pmu-events/jevents.c:_Noreturn void     _Exit(int);
...
/usr/src/sys/netinet/libalias/alias_proxy.c:    _Alignas(_Alignof(u_short)) u_char option[OPTION_LEN_BYTES];
...
                                            
/usr/src/sys/kern/kern_tc.c:    _Static_assert(_Generic(((struct timehands *)NULL)->member,    \

Ой!


Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

96. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 16:50 
> "too slow to innovate" (©ВеликийОпеннетныйОналитег)!

Чувак из ixsystem который это выдал про опеннет вообще наверное не знает. А версия компилера сама по себе - ну, это такая очень внутреннея инновация, которая никому кроме кодеров не интересна.

Отдельная ода славы инноваторам типа гангстера Масика. Вот это был инновационный подход к разработке софта, надо было еще какой-нибудь налет на банк, или ограбление дилижанса, чтоли, организовать. Тогда сюжет можно было бы продать кинокомпании. Впрочем, может и так купят :)

Ответить | Правка | Наверх | Cообщить модератору

97. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 17:50 
>> "too slow to innovate" (©ВеликийОпеннетныйОналитег)!
> Чувак из ixsystem который это выдал про опеннет вообще наверное не знает.

Да не, это выдал ты - прочитав опять что-то, каким-то местом (нет, не глазами), а не чувак из iXsystems. Ему ты это, как обычно, только приписал.
Причем, до этого Великий Оналитег там же, гордо озвучил чей-то вопрос в форуме, как оф. заявление разработчиков.

> 1) Нормальные типы данных. Простите, int - это очень неконкретно. Может быть 16 битов, а может и 64. А теперь попробуйте на этом математику сделать без багов и кроссплатформенно, ню-ню. Даже у большинства аксакалов код обгаживается на этом только в путь.

...
> Самолично хреначить детект истинных размеров типов и из этого крафтить потребные exact width типы, обвесив столь же самопальными квазиассертами из гамна и палок вида #define assert(cond, why) typedef char why[cond ? 1 : -1] - это имнено оно! И даже еррор при обломе - кривой. А в C11 это все есть сразу и не через зад.

...
> А версия компилера сама по себе - ну, это такая очень
> внутреннея инновация, которая никому кроме кодеров не интересна.

Какое занятное переобувание в прыжке, однако.
Ну и эталон "избирательного чтения" - там читаем, там:
>> Связанная со Spectre проблема в коде была вызвана продолжением использования отдельно определяемого итератора после цикла - для перебора элементов связанного списка используется макрос и так как итератор цикла передаётся в этот макрос, он определяется вне самого цикла и остаётся доступен после цикла. Использование стандарта C99 позволило бы определять переменные для цикла в блоке for(), что решило бы проблему без придумывания обходных путей.

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


> Отдельная ода славы инноваторам типа гангстера Масика. Вот это был инновационный подход
> к разработке софта, надо было еще какой-нибудь налет на банк, или

И к чему был этот очередной спрыг? Кстати, уже выпилили ФС рейзера или пока что "это другое!"?


Ответить | Правка | Наверх | Cообщить модератору

129. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (-), 01-Мрт-22, 23:33 
> Причем, до этого Великий Оналитег там же, гордо озвучил чей-то вопрос в
> форуме, как оф. заявление разработчиков.

Это какой-то юзер там, довольно наглый - запостил перевод с манагерского на английский. Хороший перевод, именно это манагер и имел сказать.

И не думаю что там кого-то версия C интересовала. Это не те инновации которые можно продать, в лучшем случае это кодерам небольшая улучшалка. Но знаешь, выбирая между "пережить без C11" и "пережить без [дрова на много всего]" - сами понимаете.

> Какое занятное переобувание в прыжке, однако.

Вам как эксперту виднее.

> Так-то интересы кодеров почему-то частенько напрямую затрагивают пользователей.

Они весьма косвенно увязяны.

> И к чему был этот очередной спрыг? Кстати, уже выпилили ФС рейзера
> или пока что "это другое!"?

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

Ответить | Правка | Наверх | Cообщить модератору

95. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (-), 26-Фев-22, 16:47 
> А у FreeBSD какой стандарт си?

Юрского периода.

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

98. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 26-Фев-22, 17:57 
>>> А у FreeBSD какой стандарт си?
>> /usr/src/sys/kern/kern_tc.c:    _Static_assert(_Generic(((struct timehands *)NULL)->member
> Юрского периода.

Т.е. те древние времена до изобретения бананового смузи с овсяными хлопьями?

Ответить | Правка | Наверх | Cообщить модератору

130. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Аноним (-), 01-Мрт-22, 23:33 
> Т.е. те древние времена до изобретения бананового смузи с овсяными хлопьями?

Сейчас в моде немного другие ингредиенты для смузи.

Ответить | Правка | Наверх | Cообщить модератору

111. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Sin2x (ok), 27-Фев-22, 19:33 
Они ориентируются на более широкий стандарт POSIX, который сейчас на C99.
Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

74. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (-), 26-Фев-22, 12:44 
Текущий ратифицированный стандарт языка Си это C18. C17 - это всего лишь промежуточный черновик.
Ответить | Правка | Наверх | Cообщить модератору

103. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Ordu (ok), 26-Фев-22, 23:09 
NOOOOOOO! Не может быть. Это же combo breaker. Они все нечётные. И у c++ тоже. C18 это неумелый фейк.
Ответить | Правка | Наверх | Cообщить модератору

104. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от ананас (?), 27-Фев-22, 11:25 
Грамотно было бы на MISRA C, но это нужно уметь правильно писать.
Ответить | Правка | Наверх | Cообщить модератору

114. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  –1 +/
Сообщение от Аноним (53), 28-Фев-22, 07:40 
Ну так не ставили задачу писать в соответсвии с MISRA. Поставят - научатся.
Ответить | Правка | Наверх | Cообщить модератору

124. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +2 +/
Сообщение от Брат Анон (ok), 01-Мрт-22, 15:40 
> Грамотно было бы на MISRA C, но это нужно уметь правильно писать.

В том-то и дело. Никто не умеет писать грамотно на Си, даже те кто придумал мисру. Потому что Си -- сочинён. а не спроектирован.

Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

118. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Брат Анон (ok), 28-Фев-22, 14:49 
С11?? В ядро?! Ну и хипстер.
Ответить | Правка | Наверх | Cообщить модератору

122. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от deeaitch (ok), 01-Мрт-22, 07:00 
Ну не раст жешь
Ответить | Правка | Наверх | Cообщить модератору

123. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Брат Анон (ok), 01-Мрт-22, 15:39 
> Ну не раст жешь

Я не знаю, что такое Раст. Его ещё не изобрели. Но стандарт, которому всего 11 лет (школьный т.е.) в ядро пихать ну никак нельзя. С89 ещё куда ни шло. Этот хоть отлежался малька.

Ответить | Правка | Наверх | Cообщить модератору

133. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от deeaitch (ok), 04-Мрт-22, 04:59 
> Я не знаю, что такое Раст. Его ещё не изобрели.

Вот тут ты 100% прав

> Но стандарт, которому всего 11 лет (школьный т.е.)

Ему не 11 лет. Ему минимум 22. Ты не с той стороны считал. Его 22 года собирали и обсуждали чтобы в 11-ом принять

Ответить | Правка | Наверх | Cообщить модератору

135. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +1 +/
Сообщение от Брат Анон (ok), 09-Мрт-22, 14:05 
> Ему не 11 лет. Ему минимум 22. Ты не с той стороны
> считал. Его 22 года собирали и обсуждали чтобы в 11-ом принять

А, ну тогда норм!)

Ответить | Правка | Наверх | Cообщить модератору

136. "В ядре Linux 5.18 планируют разрешить использование стандарт..."  +/
Сообщение от Neon (??), 16-Мрт-22, 01:49 
Не прошло и пол года.))) Быстренько они)))
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру