В процессе обсуждения набора патчей с исправлением связанных с уязвимостями класса Spectre проблем в коде для работы со связанными списками, стало ясно, что проблему удалось бы решить более изящно, если бы в ядро допускался код на языке Си, соответствующий более новой версии стандарта. В настоящее время добавляемый ядро код должен соответствовать спецификации ANSI C (С89), сформированной ещё в 1989 году...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56760
> Си C11ну вот наконец си си кэпвелл и вышел из комы
Алилуя, давно пора. А, кэпвеллу дивный новый мир не понравится, пичалька.
Это 152400-я серия Санта-Барбары? Меня удивляло то, что вполне респектабельные уважаемые театральные актёры России тащились от этого третьесортного сериала масштаба одного штата, Калифорния кажется. Потом я узнал что этот сериал в даже своём штате имел низкие рейтинги. Оказывается мои знакомые американцы вообще не знали про существование этого сериала. 1990-е российские федеральные телеканалы закупали третьесортные сериалы и скармливали их собственному населению. "Богатые тоже плачут" это вообще сериал 1970-х гг. Копец! Мексиканцы удивлены.
Понять бы только, с чего тебя так бомбануло.
> Понять бы только, с чего тебя так бомбануло."Анонимов тоже бомбит!" - высокорейтинговый сериал опеннета, 1996-2022 год
За отсутствием сериалов марвела и диснея - сойдет. Экранизуйте.
Весна же. Чуть раньше календарной в этом году.
Почему "тащились"? Очень просто - потому что другого *ничего* не было. На безрыбье, как говориться...
Ну логично, совковому зрителю вообще можно было что угодно скормить, да и потом, насколько я понимаю, 99% шоу были передраны или перекуплены с Запада. И брали, понятно, что попроще сделать да подешевле купить
> настоящее время добавляемый ядро код должен соответствовать спецификации ANSI C (С89), сформированной ещё в 1989 году.Зачем использовать такую старую спецификацию, всем смысл?
А в чём ранее был смысл использовать более новую?
Да хотябы вот C11 "Интерфейсы для проверки границ массива"
Самый лучший интерфейс для этого -- межушный.
Использование третьей версии языка (9899-2011) в ядре ради его безопасных конструкций, в частности это for с объявлениями в expr1. Также с С11 есть атомарные фундаментальные типы.
> А в чём ранее был смысл использовать более новую?1) Нормальные типы данных. Простите, int - это очень неконкретно. Может быть 16 битов, а может и 64. А теперь попробуйте на этом математику сделать без багов и кроссплатформенно, ню-ню. Даже у большинства аксакалов код обгаживается на этом только в путь.
2) Стандартизация того что есть true и false в булеанах, устаканеная работа с этим всем, в частности, assignment чего либо кроме нуля ведет к assignment единицы и рассмотрению как true, в самопальных реализациях возможны самые разные варианты. Что добавляет багов и глюков, а кодер не знает чего ожидать.
3) Вариадики, особенно макросы, годная штука. Вариадик функции в ядро тащить не стоит, пожалуй, но макросы можно делать и относительно беззубыми.
4) Static Assert есть. На более ранних сях аналог сделать можно - но нельзя получить красивое сообщение об ошибке стандартными средствами если условие провалилось.
Ты сейчас с кем говорил?Давай в контексте ядра Линукс.
У них большая часть этого есть. Только наколенно.
Любишь все блестящее и бесполезное?
Любишь тупые баги в математике, с overrun'ами/negative index deref и вообще уродский код? Я видел достаточно такого кода чтобы научиться его ненавидеть :)Линуксоиды так то подобие C99/11 и из 89 сделали себе. И более вменяемые типы, и статик ассерты, и прочие плюшки. Только это очень уж педальненько было.
Вроде пишется по конкретный компилятор? А про остальные портируется (с ответственностью на тех, кто портирует). Или я чего то не понимаю? Зачем тащить скраб, когда он не нужен? Зачем синтаксический сахар, когда он вносит больше неопределённости?
> Вроде пишется по конкретный компилятор?Оно как бы так стало не потому что так всем очень нравится, а потому что в стандарте НЕТ некоторых вещей требующихся для написания ядер, бутлоадеров, фирмварей и прочего. Номинально есть freestanding, но он только о том что кто должен и не должен реализовывать. А про то как разместить вот эту функцию в вон той секции, и как кастомно компоновать адресацию, лэйаут памяти и проч - там ничего нет. И тут оказывается что вот эта хрень - компилер специфична. И вы либо вообще обламываетесь, либо кодите под кого-то конкретного. Используя extended фишки которых в стандартах НЕТ.
Со временем GCC как-то стал более-менее золотым стандартом этсамого. И даже шланг и в меньшей степени другие, типа tcc какого-нибудь, стали обезьянить как некоторые нестандартные вещи делаются. Сейчас ядро линуха и clang'ом вроде собирается, плюс-минус. У оного мощный статический анализатор, лишний раз код прозвонить - идея некоторым нравится.
> А про остальные портируется (с ответственностью на тех, кто портирует).
> Или я чего то не понимаю? Зачем тащить скраб, когда он не нужен?Можно самому изобретать велик, при том - с ржавой рамой из водопроводных труб и деревянными колесами, потому что под рукой ничего лучше не было, так что слепили подобие велика из того что есть. Ездит же как-то? А можно и более нормальный взять, если уж есть.
> Зачем синтаксический сахар, когда он вносит больше неопределённости?
Никакой неопределенности оно не вносит. А делать велосипед самому из ржавых труб может и задолбать, особенно если можно и получше чем это. Самолично хреначить детект истинных размеров типов и из этого крафтить потребные exact width типы, обвесив столь же самопальными квазиассертами из гамна и палок вида #define assert(cond, why) typedef char why[cond ? 1 : -1] - это имнено оно! И даже еррор при обломе - кривой. А в C11 это все есть сразу и не через зад.
>> А в чём ранее был смысл использовать более новую?Нативная поддержка типов, и bool в частности, это не только отсутствие необходимости включать заголовочные файлы, а то что сам компилятор о них знает, как проверять и оптимизировать.
А то, помню ржали над одной поделкой где bool складывали, и это ж работало.
> Нативная поддержка типов, и bool в частности, это не только отсутствие необходимости
> включать заголовочные файлы, а то что сам компилятор о них знает,
> как проверять и оптимизировать.1) Вообще-то включать хидеры по стандарту для этого надо. С определениями этсамого.
2) И ващет складывать бульоны так никто и не запрещает. Они внутрях мапятся в какой-нибудь integer. НО КОЕ ЧТО ВСЕ ЖЕ ОТЛИЧАЕТСЯ.Есть простой пример:
uint8_t boolvalue = 0; // false, типа.
...
boolvalue = 256; // ...но готовы ли вы к тому что вот так - тоже false?А вот если это boolean, любое присвоение которое не ноль по стандарту рубится до 1. И соответственно, вон то - тоже true. Ну, если вы не 0 хотели, очевидно, это было не про false?!
Во всяком случае это - четко определенное и довольно логичное поведение, а не implementation defined (как в компилере, так и в самопальных макро) с более 9000 разных вариантов как это вообще может быть - и таким же колиеством багов, когда идеи кодеров и компилеров о том как это считается не совпали.
> А то, помню ржали над одной поделкой где bool складывали, и это ж работало.
Яваскриптеры наверное. У них такое норма жизни, вплоть до того что +1 и ++ может довольно разные вещи означать =)
> 1) Нормальные типы данных. Простите, int - это очень неконкретно. Может быть 16 битов, а может и 64. А теперь попробуйте на этом математику сделать без багов и кроссплатформенно, ню-ню. Даже у большинства аксакалов код обгаживается на этом только в путь.у каждого типа есть гарантированный низ размерности. использование фиксированных типов ухудшает портабельность, а лимиты считать всё равно придётся. в общем, непонятной категоричности высказывание.
остальное не тянет на обсуждение - хотелки.
> у каждого типа есть гарантированный низ размерности.По факту большая часть кода не готова к тому что int будет 16 бит, равно как и char. По стандарту так можно было.
> использование фиксированных типов ухудшает портабельность,
Если кто не снялся с тормоза за 22 года, это его проблемы, имхо. Это все умеет даже tcc и sdcc какой-нибудь, под недоношеных 8-биток. Если у кого-то платформа большее дно чем ЭТО, сие его проблемы.
> а лимиты считать всё равно придётся. в общем, непонятной категоричности высказывание.
Неа. Если я сказал uint8_t - он 8 битов и я могу на это уповать. И либо оно так, либо это не компилится. Второе - проблемы дохлой платформы, а не мои. Вы или соответствуете пререквизитам, или я вам ничего и не обещал. Да, C99 compiler везде заявлен как build dep. А абстрактным unsigned int сами странные баги собирайте.
> остальное не тянет на обсуждение - хотелки.
А почему бы мне не хотеть пользоваться нормальными тулзами? Штатные типы си это жесть, как и тот миндфак который он делает с integer promotions
Как определенность в размере типов ухудшает портабельность ?!
Лишь бы C++ не использовать.
>А в чём ранее был смысл использовать более новую?Да вот только за отсутствие возможности написать for (int i=0; i<n; i++), С89 следовало бы давно выжечь.
И это тоже. Полно случаев когда i объявили, сделали большой кус, сто раз забыли как объявили, лоханулись по тупому, ...А можешь объяснить пойнт (signed) int в данной конструкции? А то вот такие вот чудеса очень любят уходить в минус, потому что могут, особенно если оно из параметра caller'а считается... и потом получается интересно. Потому что (signed) с большим минусом < n так то довольно долго выполняеться может... а если это еще и индекс в массиве был, вам точно амба
Говорить не запретишь, но в ядре... Хотя молодость
Ну стандарт языка считает, что уйти в минус оно не может, а в случае с unsigned приходится гарантировать правильное переполнение, это может стоить не так мало (вот пример: https://youtu.be/yG1OZ69H_-o?t=2357 — наверное, правильным фиксом было бы использование size_t, но они под настолько экзотические платформы делают вид, что собираются, что до сих пор не сделали ничего).
Изначально смысл был что бы собирать ядро под платформы где компиляторы частично поддерживают стандарты, а таких и сейчас как грязи, не поддерживающих полностью не только C11, но и gnu99.
Далее было лень, наверное, обновлять требования к компиляторам.Но, это не могло длиться вечно, и наконец то обновляются. Молодцы.
Никогда не было, ядро никогда ничем кроме gcc нормально не собиралось. Даже для llvm, старавшегося сохранить совместимость, пришлось в куче мест править.
Изначально был смысл чтобы собирать ядро под платформы, для которых нет и не факт что будет когда-нибудь моднейшая версия gcc. Скажи спасибо если есть кое-как когда-то портированный вендором 2.7.2Да, внезапно на таких платформах тоже мог кому-то понадобиться линукс.
Сегодня вот внезапно выяснилось, что поскольку ниже пятой версии вообще уже давным-давно не собирается, в основном из-за static_assert поди, незачем особо и стараться.
> Скажи спасибо если есть кое-как когда-то портированный вендором 2.7.2Тогда оно умерло и это проблемы некромансеров что делать дальше.
> Да, внезапно на таких платформах тоже мог кому-то понадобиться линукс.
Пусть юзают ядра современные компилеру, например :)
> незачем особо и стараться.
Это их проблемы. Те кто в майнлайне присутствует - собираются чем-то явно менее некромансерским. А если вы там сбоку на коленке где-то абы как, ну, вот, заодно и винтажное ядро будете для себя майнтайнить вместе с компилером.
TL;DR: никто не будет делать из ваших проблем свои. Абыдна, да?
то есть л@п4оподелка должна оставаться на тех двух платформах, которые одобрила ibm?
Ну ок, все правильно, зачем ее еще куда-то портировать. Профита ibm с этого никакого, и другим платиновым тоже, ведь там поди и винды-то нет."те кто в мэйнлайне присутствуют" - присутствуют там именно потому что кому-то в свое время удалось этих присутствующих собрать и портировать платформозависимые части. Ну, такими темпами - ненадолго.
Нет, трахаться с портированием версии 1.0.102 "современной компилеру" никто не будет, это мартышкин труд.
Поищут просто менее хипстерскую систему для своей платформы, которую можно собирать более общедоступными компиляторами.
То-есть актуальное ядро живет на актуальных платформах, на которые комьюнити или вендор не забили. Т.е. пока есть те кто майнтайнит это. Они не как бзды, помойкой для подачек быть не собираются. Код или майнтайнится - или сперва в staging, потом если всем пофиг, труп считается трупом и уносится в морг. Правила просты.И мне плевать что там с платформами на 2.7.каком-то gcc, я меньше 7 уже сто лет не видел.
Не будут трахаться с портированием? Тем хуже для них, я тоже не собираюсь пользовать окаменелый кал без нормальной диагностики, статического анализа и оптимизаций с кучей ископаемых багов. Поможет платформе помереть быстрей, куда и дорога. Это не мои проблемы - я просто другую возьму. А что эти некромансеры поищут мне не интересно. Как показала практика, их клиенты на раз поищут менее @#$%нутую фирму с которой проще иметь дело в таком случае. В каких-то совсем нишевых случаях может и не поищут, но это будут сильно нишевые системы. И даже им постепенно амба наступает, я так то помог вынести кой кому окаменелый куникс на который все забили так то. Не, он им не нужен был, просто манагерье 100500 лет взяло его потому что круто. Реалтайм им был нафиг не.
> Никогда не было, ядро никогда ничем кроме gcc нормально не собиралось.Не под всякую архитектуру и gcc актуальной версии есть.
>Скажи спасибо если есть кое-как когда-то портированный вендором 2.7.2А дальше ядра-то что? GLibc нужен C99. Думаю, Musl'у тоже не менее.
а дальше можно хотя бы пытаться собрать gcc штатным образом.> GLibc нужен C99.
glibc до недавнего времени был кросплатформенным. То есть усилия по портированию минимальны, можно взять тот что попроще. А вот портировать кросс-компилятор (потому что native нет и быть для этой архитектуры не может) без работающей системы - это так себе развлечение.
> а дальше можно хотя бы пытаться собрать gcc штатным образом.Пох вам расскажет как сделать все дерьмово и сложно. Но есть и способы лучше.
1) Берем нормальный компилер на своем хосте, типа свежего гцц из своего дистро. Не надо быть при этом как пох, если вашему дистро более 5 лет, выньте скелетов из шкафа уже и поставьте что-то менее архаичное, нормальный компилер этого уж точно стоит. Им собираем себе кроссовый gcc, хоть самый свежий. Это быстро и если вы не используете на хосте окаменелый кал или прочие маздаи - довольно просто к тому же. GCC обычно может сам себя собрать минуя фазу бутстрапа, так что с места в карьер непохабный компилер под таргет.
2) А вот этим уже можно собрать себе ядро, бутлоадеры и проч как белый человек.
> native нет и быть для этой архитектуры не может) без работающей
> системы - это так себе развлечение.Если архитектура в gcc поддерживается то самому кросс собрать - ну ваще не напряг. А если не поддерживается - какой задницей вы думали когда это железо вообще брали? Будете вместо вендора этого кала компилер кодить вместо реализации своей задачи? Ну, удачного бизнеса с таким подходом, можете и заяву о банкротстве заполнить заранее, пригодится: если из чужих проблем делать свои, бизнес долго не протянет.
В поддерживаемом компилляторе , конечно же
А почему не C17, который более модерновый?
Написанно же:> Рассматривалась возможность и использования стандарта C17, но в этом случае пришлось бы повышать минимально поддерживаемую версию GCC
>пришлось бы повышать минимально поддерживаемую версию GCCИ в чем проблема? Некрофилы всякие все равно сидят на LTS.
>>пришлось бы повышать минимально поддерживаемую версию GCC
> И в чем проблема? Некрофилы всякие все равно сидят на LTS.Это для intel и arm всё хорошо с компиляторами, но есть и менее популярные платформы, под которые собирают ядро, и там явно распространены компиляторы не осилившие поддержку _полностью_ с17.
С заботой о неосиляторах.
о как... а выше тролли говорили про "никто не будет решать проблемы неосиляторов, абидна да".
Интересно что за платформы такие.
Отвлекись от х86 и найдешь кучу таких платфром.
...которые благополучно сдохли в лучшем случае ещё в нулевых
Написано ж почемуРассматривалась возможность и использования стандарта C17, но в этом случае пришлось бы повышать минимально поддерживаемую версию GCC
И, главное: назовите вашу любимую фичу C17 которой нет в C11? А, погодите, 17 это такая слегка исправленная версия 11, в которой для разработке кернелов нет почти ничего полезного? Нну...(да, если кто не понял ядро не сможет пользоваться плюшками стандартной либы, так что всякие продвинутости типа тредов и проч - ну, сами понимаете, не про ядро, оно слишком кастомное чтобы ему стандартная либа катила, у него все свое, "почему-то")
Читать надо внимательней.
С17 содержит практиечски только косметические изменения, не затрагивая по существу ничего в самом языке.
> Линус Торвальдс согласился с идеей реализации поддержки более новых спецификацийя более довольный
Си всё ближн к переходу на быстрый и безопасный язык zig.
Забавная штука, лучше хруста на вид. Но пока дико нестабильная, а некоторые тестимониалы дико доставляют. Посмотри про сборку таким манером lwan :)). Тестимониал в виде "...complete failure" все же рановат для серьезного применения.
Автор вроде так и говорит надо ждать версию 1.0
> Автор вроде так и говорит надо ждать версию 1.0Хруст это за 10+ лет не смог. Эти имеют более резвые планы? А то моя фамилия, увы, не McLeod чтобы такими вещами не париться :)
>Линус Торвальдс [...] предложил перейти на использование стандарта C11Почему не 99? Он в разы более подтдерживаемый, чем 11-ый, да и проблем с совместимостью будет меньше (если они будут, конечно)
Так, глядя на часы, сейчас 2022 вообще-то. И если кто за 11 лет не расчехлился, он, наверное, сдох. И нет, ждать по 22 года это все же перебор. Ну и статик ассерты пригодятся. И генерики позволяют в принципе более красивые и менее бажные вещи типа min/max без форсирования типа аргументов на гвозди, например. На макросне так сделать можно, но багов при этом... потому что у препроцессора очень сильно свои идеи как он аргументы жрет, он вам тут не компилер.
> Почему не 99? Он в разы более подтдерживаемый, чем 11-ыйМинимальные версии компиляторов, нужных ядру, поддерживают 11. Так что ни чего не случиться.
> проблем с совместимостью будет меньше (если они будут, конечно)
Если они будут - не очень большие, C достаточно стабилен.
> Он в разы более подтдерживаемыйЧто на что делил анонимус?
> Что на что делил анонимус?Плюс бесконечность на NaN :)
Насколько я знаю, любая операция с NaN определена и результат равен NaN
> Насколько я знаю, любая операция с NaN определена и результат равен NaNЭ... то-есть наконец можно поделить на ноль? :)
дык кем "в разы поддерживаемый"-то? Проблема с совместимостью с чем-то более ранним чем насквозь гнилой и глючный пятый gcc (хотя бы уже достаточно в свое время залатанный 4.7) давно непроблема - ведро с ними несовместимо и сборку таким "немодным устаревшим дерьмом" не поддерживает."зато сообщения об ошибках красивенькие!"(c) кто-то из местных.
Как будто, внятные и выделенные сообщения об ошибках это недостаток.
Если для этого тебе придется на неведомую х-ню с необычной архитектуркой спортировать gcc - ты как запоешь? А, ну да, ну да, ты же не умеешь кодить...
Один ты тут, ля, умеешь.
Хотел сказать, что чем тупее собщения компилятора, тем легче его портировать? Да, ты-то знаешь толк в кодинге.
> Если для этого тебе придется на неведомую х-ню с необычной архитектуркой спортировать
> gcc - ты как запоешь? А, ну да, ну да, ты же не умеешь кодить...Ну, наверное, все же не так как при нужде портировать туда еще и хруст :)))
С хрустом пока можно погодить - CoC.md и копипасту gpio драйверка можно первое время на такой платформе не поддерживать.Даже если это и зайдет дальше (запихнут, гуглю дури хватит), те гугль-онли драйверы там тоже будут без надобности еще долго.
Да они пока там на core level своей вундерфафли гамно лаптем хлебают, на каждую новую итерацию патча новые причины и фичи, которые уже почти включены в следующую версию ночного горшка^W билда, так чот вот-вот станет збс. А пока запустите с нашего сайта бэкдор^W майнер^W шелскрипт который вам тут типа-отстроит что-то...
> Если для этого тебе придется на неведомую х-ню с необычной архитектуркой спортировать
> gcc - ты как запоешь?Я скажу что не подписывался делать вендорскую часть работы, бесплатно, вместо кодинга моей задачи - и возьму какую-нибудь другую платформу. А с буя ли я должен за производителя железки вкалывать? Я что, идиот покупать железо под которое компилера нет и сам его писать?
> Почему не 99?В нём почти всё было ошибкой, труъ сишники его обычно презирают.
> В нём почти всё было ошибкой, труъ сишники его обычно презирают.На коде этих господ очень интересно запускать фуззинг и статический анализ. А потом их презирают не только хрустики, но и остальные сишники. Потому что напыщеные багоделы с уязвимым кодом - это не круто ни в раз. И это д@рьмо мы из вас таки выбьем совместными усилиями...
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
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?Он же
-Wno-shift-negative-value а много где оно есть? В принципе это чистое UB. Неужели проще подавить предупреждение, чем почистить код? Надо бы проверить а то патч сделать.
Мб временно
https://m.youtube.com/watch?v=QpAhX-gsHMsВот теперь заживём.
> пришлось бы повышать минимально поддерживаемую версию GCC.Да уж, не надо задирать без особой надобности.
Дещять лет ждал этого! (с)
>предложил перейти в ядре 5.18 на использование стандарта C11, опубликованного в 2011 году.Шёл 2022 год.
Не шёл, а идёт. Не наркомань.
Хорошо, пусть будет так :)
> Не шёл, а идёт.Шёл, идёт, и будет есть.
Сижу на БАД'ax
После слова "изящно" перестал читать
> После слова "изящно" перестал читатьВы не любитель изящных искусств? Поклонник брутала? :)
я вообще слово изящно считаю неприменимым к программированию.
Здравствуй, единомышленник! Я так же думаю про слово "морошка".
"морошка" не имеет отношение ни к чему кроме ягод. Ты о чём?
> я вообще слово изящно считаю неприменимым к программированию.Какой-нибудь Кнут с этим очень крепко не согласится. Но из-за таких считал программирование и скатилось в вебмакакинг и джамшутинг.
> Какой-нибудь Кнут с этим очень крепко не согласится. Но из-за таких считал
> программирование и скатилось в вебмакакинг и джамшутинг.Извиняюсь, я практик просто
> не возникнет непредвиденных проблемДа уж. В стандарте как в 11 так и в 17, не говоря про предидущие, американским по делому сказано что непредвиденое поведение ДОЛЖНО обрабатываться програмером. И в дополнение к этому выпустили целых два документа про безопасному программированию/кодированию на С и С++. И это ещё не Дейтейлв с Сикордом рекомендоваи, а целый АНСИ коммитет.
Все знают что проблемы возникнуть могутбыть, и что их обрабатывать нужно. Но никто за это зарплаты не получает и не обрабатывает.
Поэтому и баков куча.
Луддиты какие-то…
А у FreeBSD какой стандарт си?
Не знаю.
Почему?
> Почему?Потому что не умеет плюсами опенсорса пользоваться. "Сорцы не читал но осуждаю!"
> А у 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, \
Ой!
> "too slow to innovate" (©ВеликийОпеннетныйОналитег)!Чувак из ixsystem который это выдал про опеннет вообще наверное не знает. А версия компилера сама по себе - ну, это такая очень внутреннея инновация, которая никому кроме кодеров не интересна.
Отдельная ода славы инноваторам типа гангстера Масика. Вот это был инновационный подход к разработке софта, надо было еще какой-нибудь налет на банк, или ограбление дилижанса, чтоли, организовать. Тогда сюжет можно было бы продать кинокомпании. Впрочем, может и так купят :)
>> "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 интересовала. Это не те инновации которые можно продать, в лучшем случае это кодерам небольшая улучшалка. Но знаешь, выбирая между "пережить без C11" и "пережить без [дрова на много всего]" - сами понимаете.
> Какое занятное переобувание в прыжке, однако.
Вам как эксперту виднее.
> Так-то интересы кодеров почему-то частенько напрямую затрагивают пользователей.
Они весьма косвенно увязяны.
> И к чему был этот очередной спрыг? Кстати, уже выпилили ФС рейзера
> или пока что "это другое!"?Это все то же что и обычно: код должен майнтайниться. Если он не майнтайнится, его выкидывают. Пока не выкинули - использование упомянутого апи отломали, претензия отпала. Но вообще это намек что тот код никому не вперся уже много лет.
> А у FreeBSD какой стандарт си?Юрского периода.
>>> А у FreeBSD какой стандарт си?
>> /usr/src/sys/kern/kern_tc.c: _Static_assert(_Generic(((struct timehands *)NULL)->member
> Юрского периода.Т.е. те древние времена до изобретения бананового смузи с овсяными хлопьями?
> Т.е. те древние времена до изобретения бананового смузи с овсяными хлопьями?Сейчас в моде немного другие ингредиенты для смузи.
Они ориентируются на более широкий стандарт POSIX, который сейчас на C99.
Текущий ратифицированный стандарт языка Си это C18. C17 - это всего лишь промежуточный черновик.
NOOOOOOO! Не может быть. Это же combo breaker. Они все нечётные. И у c++ тоже. C18 это неумелый фейк.
Грамотно было бы на MISRA C, но это нужно уметь правильно писать.
Ну так не ставили задачу писать в соответсвии с MISRA. Поставят - научатся.
> Грамотно было бы на MISRA C, но это нужно уметь правильно писать.В том-то и дело. Никто не умеет писать грамотно на Си, даже те кто придумал мисру. Потому что Си -- сочинён. а не спроектирован.
С11?? В ядро?! Ну и хипстер.
Ну не раст жешь
> Ну не раст жешьЯ не знаю, что такое Раст. Его ещё не изобрели. Но стандарт, которому всего 11 лет (школьный т.е.) в ядро пихать ну никак нельзя. С89 ещё куда ни шло. Этот хоть отлежался малька.
> Я не знаю, что такое Раст. Его ещё не изобрели.Вот тут ты 100% прав
> Но стандарт, которому всего 11 лет (школьный т.е.)
Ему не 11 лет. Ему минимум 22. Ты не с той стороны считал. Его 22 года собирали и обсуждали чтобы в 11-ом принять
> Ему не 11 лет. Ему минимум 22. Ты не с той стороны
> считал. Его 22 года собирали и обсуждали чтобы в 11-ом принятьА, ну тогда норм!)
Не прошло и пол года.))) Быстренько они)))