forum.opennet.ru - "GCC 15 будет использовать стандарт C23 по умолчанию" (101)

"GCC 15 будет использовать стандарт C23 по умолчанию"

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

"GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от opennews (?), 23-Ноя-24, 21:46
В кодовую базу, на основе которой формируется запланированный на весну следующего года выпуск набора компиляторов GCC 15, принято изменение, включающее по умолчанию использование стандарта С23 с расширениями GNU ("-std=gnu23") при компиляции программ на языке C (ранее по умолчанию использовался стандарт C17 - "-std=gnu17"). Изменение потенциально может привести к проблемам при сборке существующих проектов, так как в новом стандарте имеются отличия, такие как добавление типов nullptr и _BitInt(n), а также появление ключевых слов bool, true и false, которые могут конфликтовать с заданными в приложениях одноимёнными идентификаторами... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62278
Ответить \| Правка \| Cообщить модератору

Оглавление

Ну надо же, bool true false подвезли Я дожил до этого момента , ДаНуНафиг (?), 21:46 , 23-Ноя-24, (1) +14

А те, кому реально это было нужно 8212 не ждали и использовали stdbool h , н, Аноним (8), 22:32 , 23-Ноя-24, (8) +3

Вообще довольно странно рассуждать о примитивных типах как о реально нужных ил, Анон28679234 (?), 02:39 , 24-Ноя-24, (68) +5

Судя по современному вебу, сайты только так и пишут вставляют паяльник в обезья, Герострат (?), 09:55 , 24-Ноя-24, (129)

Это еще что Как тебе такое Элон Маск А вот тут всем микроконтроллерщикам, Аноним (-), 03:35 , 24-Ноя-24, (72)

Хочу смеяться пять минут , Аноним (121), 09:32 , 24-Ноя-24, (121)

Скрыто модератором, Аноним (2), 21:58 , 23-Ноя-24, (2) +2

Скрыто модератором, Блюститель лицензий (?), 22:03 , 23-Ноя-24, (4) +5

Скрыто модератором, Маковод (?), 22:19 , 23-Ноя-24, (5) +4

Скрыто модератором, Аноним (8), 22:38 , 23-Ноя-24, (10) –2

Скрыто модератором, Маковод (?), 23:00 , 23-Ноя-24, (14)
Скрыто модератором, YetAnotherOnanym (ok), 23:33 , 23-Ноя-24, (20)

Скрыто модератором, Аноним (31), 00:11 , 24-Ноя-24, (31) –1

а это зачем , Аноним (6), 22:25 , 23-Ноя-24, (6)

Чтоб меньше конфликтов было при всяких include и inline , bircoph (ok), 22:35 , 23-Ноя-24, (9) +2

И как 50 лет жили без этого , Аноним (6), 23:23 , 23-Ноя-24, (17) –3

С матами и постоянными переименованиями всего и вся лишь бы этот комп-депилятор , Аноним (32), 00:14 , 24-Ноя-24, (32) +5
Жили же тысячи лет в пещерах и ничего , Аноним (39), 00:25 , 24-Ноя-24, (39) +3
Ну, как, как, городили костыли типа ifndef HAVE_WTF_H define HAVE_WTF_H основ, Аноним (-), 06:55 , 24-Ноя-24, (95)

Теперь не будут , Аноним (6), 09:44 , 24-Ноя-24, (126)

Нужно больше неопределённого поведения Потом, когда вылезут очередные уязвимост, Аноним (7), 22:30 , 23-Ноя-24, (7) +4

Ничего удивительного, в этом языке даже int int является неопределенным поведе, Аноним (11), 22:41 , 23-Ноя-24, (11) +7

Воо, это вообще лютая дичь, я до сих пор не понимаю, КАК такое возможно в языке , Аноним (31), 00:06 , 24-Ноя-24, (28)

П с а еще больше недоумеваю от тех УМВРщиков, которые в упор это не замечают , Аноним (31), 00:08 , 24-Ноя-24, (29)

Потому что системный язык должен полагаться на то как происходит сложение на апп, Аноним (32), 00:16 , 24-Ноя-24, (33) +4

Вон то на практике вело к дохреналиону багов, увы и ах А абстракции что, как во, Аноним (-), 00:41 , 24-Ноя-24, (44) +2

int a int b int maxиз этого условия можно вывести weakest predicate и прове, mister_0 (?), 00:47 , 24-Ноя-24, (48) +4

Да, но 1 Это лишняя операция 2 Половина долбоклюев это забудет 3 На практик, Аноним (55), 01:11 , 24-Ноя-24, (55) +1

у тебя есть процессор и три регистра по 32 битаты загрузил в один регистр A 0x10, mister_0 (?), 01:58 , 24-Ноя-24, (62)

Меня для начала колышет в системщине - делать доступы конкретного размера А не , Аноним (-), 07:16 , 24-Ноя-24, (96)

Если значение int a отрицательное, будет переполнение при вычитание underflow, Аноним (-), 01:16 , 24-Ноя-24, (56) +3

несомненно для отрицательных чисел нужно использовать min int, а ещё конечно не , mister_0 (?), 01:33 , 24-Ноя-24, (59)

Вместо дорогой пред-проверки с явными сравнениями и несколькими ветками можно бы, Аноним (64), 02:17 , 24-Ноя-24, (64)
Сначала проверь, что оба положительные, потом вычти одно из max int, сравни со в, Аноним (73), 04:04 , 24-Ноя-24, (73)
и теперь ты нагородил кучу проверок на пустом месте, которые ещё надо писать , Bottle (?), 09:20 , 24-Ноя-24, (118)

А простое сложение расползается кучей кода с кучей багов Спасибо, не надо, Neon (??), 05:38 , 24-Ноя-24, (79)

если a -10, то приint max - int aбудет оверфлоу, Аноним (91), 06:22 , 24-Ноя-24, (91)
Когда мне нужно было решить задачу проверки на переполнение, я использовал intpr, Аноним (122), 09:33 , 24-Ноя-24, (122)
Зачем тебе тогда си если ты собрался это проверять на каждом сложении Чтобы поб, Аноним (32), 09:55 , 24-Ноя-24, (128)

На практике ничего иного не наблюдается Языки с иными свойствами почему-то миру, 21yosenior (?), 08:41 , 24-Ноя-24, (105) +1

Практика не показатель качества - выживают не самые сильные и умные, а самые ада, Bottle (?), 09:43 , 24-Ноя-24, (125) –1

Тебе навешали лапши про какие то вульны и ты теперь истеришь не по делу , Аноним (32), 09:57 , 24-Ноя-24, (130)

Угу, именно поэтому они это не implementation-defined, не хотя бы unspecified, а, Аноним (-), 00:45 , 24-Ноя-24, (46) +2

Такова плата за генерацию эффективного кода Никто же не заставляет использовать, анон (?), 01:10 , 24-Ноя-24, (54) –2

Так ведь всё с точностью до наоборот В Си надо обложить код if ами чтобы не пол, Аноним (-), 02:50 , 24-Ноя-24, (69)
О дааа Тот самый эффективный код на Си, известный своими утечками памяти А то,, Bottle (?), 04:10 , 24-Ноя-24, (74) +2
Это называется халтура На от бись, Neon (??), 05:39 , 24-Ноя-24, (80)
Если бы не заставляли Все слёзы и ненависть обусловлена тем, что никаких иных я, 21yosenior (?), 08:44 , 24-Ноя-24, (106)

Аноним написал много латинских слов, и думает, что написал что-то умное А на сам, Аноним (73), 09:31 , 24-Ноя-24, (120)

Ну давай, расскажи мне как ты собрался из Си полагаться на то как происходит сл, Аноним (-), 00:46 , 24-Ноя-24, (47)
Пусть на ассемблере кодят, раз им нужно сложение на аппаратном уровне в конкретн, Neon (??), 05:35 , 24-Ноя-24, (78) +1
Вот только всё современное железо реализует это как two s complement, и сложение, morphe (?), 06:13 , 24-Ноя-24, (90) +1

Ты просто не умеешь этим гордиться, а они умеют , Аноним (111), 08:54 , 24-Ноя-24, (111)

Просто они знают, что ub является переполнение, а не сложение Поэтому у них всё, 21yosenior (?), 08:39 , 24-Ноя-24, (104)

ну так ты проверь перед сложением или можешь после сложения в регистр flags посм, mister_0 (?), 00:37 , 24-Ноя-24, (42) –1

в С , Аноним (49), 00:48 , 24-Ноя-24, (49)

ну придётся ассемблерную вставку сделать , mister_0 (?), 00:53 , 24-Ноя-24, (50)

А ничего что на сях мы писали - чтобы портабельно было, м , Аноним (-), 01:04 , 24-Ноя-24, (53) +1

Вы писали на сях, чтобы было быстро, а не чтобы было портабельно Оптимальное соо, Аноним (73), 09:36 , 24-Ноя-24, (123)
Вы писали на сях, чтобы было быстро, а не чтобы было портабельно Оптимальное соо, Аноним (73), 09:49 , 24-Ноя-24, (127)

А на хрена тогда С нужен Если нужно сразу на ассемблере фигачить, Neon (??), 05:40 , 24-Ноя-24, (81) +1

но я выше ответил, что проще считать post condition выводить weakest predicate и, mister_0 (?), 00:55 , 24-Ноя-24, (51)

Скажем так, единственный способ - это не использование С , Аноним (64), 02:19 , 24-Ноя-24, (65) +1

Пистон написан на си, поэтому там ситуация таже самая Раст компилируется си ком, 21yosenior (?), 08:48 , 24-Ноя-24, (108)

В си __builtin_ _overflow - 1000 лет есть , 21yosenior (?), 08:45 , 24-Ноя-24, (107)

Нет, похоже всё ещё хуже - там в новости написано Добавлена поддержка заголовоч, 21yosenior (?), 09:21 , 24-Ноя-24, (119)

В сях нет стандартного способа посмотерть флаги, внезапно Wrapround определен и , Аноним (-), 01:04 , 24-Ноя-24, (52)

Такой системный язык Близкий к аппаратуре, Neon (??), 05:41 , 24-Ноя-24, (82) –1

Внезапно он еще и про портабельность А имплементация флагов у разных процов - д, Аноним (-), 07:28 , 24-Ноя-24, (97)

Ну, у C есть ещё стандартизированные расширения из ISO IEC TR 18037 Среди кото, Аноним (111), 09:40 , 24-Ноя-24, (124)

Не позорься - написал выше этот способ Опять же, нужно меньше позориться un, 21yosenior (?), 08:55 , 24-Ноя-24, (112)

Судя по всему решение хорошее Как иначе объяснить, что весь софт написан на это, 21yosenior (?), 08:38 , 24-Ноя-24, (103)

Миллионы мух не могут ошибаться, как тут любят говорить , Аноним (110), 08:54 , 24-Ноя-24, (110)

Ты просто ретранслятор лозунгов без малейших попыток разбираться в чём-то На ин, 21yosenior (?), 09:06 , 24-Ноя-24, (116)

Значит ли это, что gcc 15 будет поддерживать стандарт c23 ПОЛНОСТЬЮ , Аноним (12), 22:46 , 23-Ноя-24, (12) +1
Всё это ерунда, есть же православный ANSI C C89 Всё остальное 8212 ненужны, Маковод (?), 23:02 , 23-Ноя-24, (15) +3

Овер инжиниринг будь проклята автозамена , Маковод (?), 23:03 , 23-Ноя-24, (16) +4

Сахар это язык zig Си это та ложка дегтя , Аноним (32), 00:19 , 24-Ноя-24, (34) –1

Вот ты на нем и прогай А я меньше чем на C99 в принципе не согласен, а лучше ми, Аноним (-), 00:34 , 24-Ноя-24, (41) +2

Расширения GNU давно пора принимать в стандарты С и С Простые и полезные идеи, nc (ok), 23:26 , 23-Ноя-24, (18) –2
llvm не лучше обоснуйте, Аноним (-), 00:23 , 24-Ноя-24, (38)

Хуже int f int p, int a p __builtin_assume_aligned p, a , 21yosenior (?), 09:04 , 24-Ноя-24, (115)

Вообще-то он указывает что функция никогда не возвращается Скажем main в фирмва, Аноним (-), 00:31 , 24-Ноя-24, (40)
14 версия при сборке пакетов ругалась на указатели, 15 будет ругаться если код н, Аноним (58), 01:20 , 24-Ноя-24, (58)
что-то фигня какая-то с auto auto myNum superCalculator 2,2 и иди гадай, ког, мяв (?), 02:59 , 24-Ноя-24, (70)

я ж правильно логику работы auto поняла , мяв (?), 03:00 , 24-Ноя-24, (71)
Какие проблемы Смотрим объявление функции В современных IDE это автоматом под, Neon (??), 05:43 , 24-Ноя-24, (84)
Значит, типизация не строгая Должно сломаться всё по цепочке А то, что ты тип в, Илья (??), 05:48 , 24-Ноя-24, (86)
Да вот блин да, научились у некоторых - а конкретно плюсеров Но порой таки - уд, Аноним (-), 07:45 , 24-Ноя-24, (99)
Зато, как славно показали себя иные адепты строгой и явной типизации и отсутстви, Бывалый Смузихлёб (ok), 08:57 , 24-Ноя-24, (113)

Зачем снова новый тип char8_t, если уже есть char и unsigned char Более того ес, Аноним (77), 05:35 , 24-Ноя-24, (77)

Почему Ы Чтоб никто не догадался , Neon (??), 05:44 , 24-Ноя-24, (85)

Так это уже не тот язык С, который придумали его изобретатели Брайан Керниган и , Аноним (87), 05:50 , 24-Ноя-24, (87) –1
Оригинальный язык С описан в книге The C Programming Language Кернигана и Ритч, Аноним (87), 05:53 , 24-Ноя-24, (88)
Также языком С лично я считаю язык представленный в книге The C Programming , Аноним (87), 06:01 , 24-Ноя-24, (89)

Требую больше постов о том, как ты игнорируешь Я большой любитель поведения люд, Аноним (-), 09:17 , 24-Ноя-24, (117)

Это меня огорчает, у меня есть ещё код в подобном стиле , ijuij (?), 06:35 , 24-Ноя-24, (92)

А так мне все нововведения нравятся, и особенно хочу отметить это 128285 , ijuij (?), 06:46 , 24-Ноя-24, (93)

Мммм Как же мне не хватало переменных длиной 3, 7, 11 бит, Аноним (101), 07:47 , 24-Ноя-24, (101)
Это ж какой простор для UB Ну и вообще, полностью идёт вразрез с идеей сишки Вс, Аноним (110), 08:53 , 24-Ноя-24, (109)

Там внедрено много кода, взгляни на коммиты в GCC https github com search q re, ijuij (?), 09:00 , 24-Ноя-24, (114)

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

1. "GCC 15 будет использовать стандарт C23 по умолчанию" +14 +/–

Сообщение от ДаНуНафиг (?), 23-Ноя-24, 21:46

Ну надо же, bool/true/false подвезли! Я дожил до этого момента!

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

8. "GCC 15 будет использовать стандарт C23 по умолчанию" +3 +/–

Сообщение от Аноним (8), 23-Ноя-24, 22:32

А те, кому реально это было нужно — не ждали и использовали <stdbool.h>, начиная с C99…

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

68. "GCC 15 будет использовать стандарт C23 по умолчанию" +5 +/–

Сообщение от Анон28679234 (?), 24-Ноя-24, 02:39

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

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

129. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Герострат (?), 24-Ноя-24, 09:55

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

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

72. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 03:35

>  Ну надо же, bool/true/false подвезли! Я дожил до этого момента!
Это еще что! Как тебе такое Элон Маск?!
> Появилась поддержка использования спецификатора constexpr для определения объектов.
А вот тут...
>  Добавлена поддержка префиксов "0b" и "0B" для указания целых значений в двоичной форме
...всем микроконтроллерщикам радоваться полчаса!

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

121. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (121), 24-Ноя-24, 09:32

"Хочу смеяться пять минут!" ©

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

2. Скрыто модератором +2 +/–

Сообщение от Аноним (2), 23-Ноя-24, 21:58

Как-то всё равно. Мой мак с macOS давно слез с Гэ-Цэ-Цэ, у которого, откровенно говоря, лицензия, которая выгодна только корпорациям.

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

4. Скрыто модератором +5 +/–

Сообщение от Блюститель лицензий (?), 23-Ноя-24, 22:03

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

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

5. Скрыто модератором +4 +/–

Сообщение от Маковод (?), 23-Ноя-24, 22:19

Финн Линус же сидит (как и большая часть кернел девелоперов).

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

10. Скрыто модератором –2 +/–

Сообщение от Аноним (8), 23-Ноя-24, 22:38

> лицензия, которая выгодна только корпорациям.
Толсто же.
GCC распространяется по лицензии GPLv3+, которая заставляет раскрывать код и делиться патентами.
Clang из макоси распространяется по лицензии Apache 2.0, не накладывающей никаких ограничений на закрытие кода.
Х–м–м, и какая же из них «выгодна только корпорациям»? Такой сложный вопрос (нет).

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

14. Скрыто модератором +/–

Сообщение от Маковод (?), 23-Ноя-24, 23:00

> Х–м–м, и какая же из них «выгодна только корпорациям»?
Любая, которая позволяет делать форки и потом коммерциализировать этот софт, который написан бесплатной мартышкой, уверовавшей в шваботку.

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

20. Скрыто модератором +/–

Сообщение от YetAnotherOnanym (ok), 23-Ноя-24, 23:33

> какая же из них «выгодна только корпорациям»?
Та, которая заставит маленький стартап выложить всё на блюдечке с голубой каёмочкой забесплатно. Для Безоса и ему подобных.

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

31. Скрыто модератором –1 +/–

Сообщение от Аноним (31), 24-Ноя-24, 00:11

> Как-то всё равно. Мой мак с macOS давно слез с Гэ-Цэ-Цэ, у
> которого, откровенно говоря, лицензия, которая выгодна только корпорациям.
Два чая адеквату. Вся эта GPL — типичный троянский конь, где под прикрытием "свободы" корпорасты получают почти даром готовые продукты и бесплатную рабочую силу.

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

6. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (6), 23-Ноя-24, 22:25

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

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

9. "GCC 15 будет использовать стандарт C23 по умолчанию" +2 +/–

Сообщение от bircoph (ok), 23-Ноя-24, 22:35

Чтоб меньше конфликтов было при всяких #include и inline.

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

17. "GCC 15 будет использовать стандарт C23 по умолчанию" –3 +/–

Сообщение от Аноним (6), 23-Ноя-24, 23:23

> Чтоб меньше конфликтов было при всяких #include и inline.
И как 50 лет жили без этого.

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

32. "GCC 15 будет использовать стандарт C23 по умолчанию" +5 +/–

Сообщение от Аноним (32), 24-Ноя-24, 00:14

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

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

39. "GCC 15 будет использовать стандарт C23 по умолчанию" +3 +/–

Сообщение от Аноним (39), 24-Ноя-24, 00:25

Жили же тысячи лет в пещерах и ничего.

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

95. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 06:55

>> Чтоб меньше конфликтов было при всяких #include и inline.
> И как 50 лет жили без этого.
Ну, как, как, городили костыли типа
#ifndef HAVE_WTF_H
#define HAVE_WTF_H
...(основная тушка)...
#endif

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

126. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (6), 24-Ноя-24, 09:44

Теперь не будут?

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

7. "GCC 15 будет использовать стандарт C23 по умолчанию" +4 +/–

Сообщение от Аноним (7), 23-Ноя-24, 22:30

> Вызов функции realloc() с нулевым размером переведён в разряд неопределённого поведения.
Нужно больше неопределённого поведения! Потом, когда вылезут очередные уязвимости из-за работы с памятью, можно будет с уверенностью утверждать, что где-то ещё оптимизатор смог ускорить работу на 0.01% благодаря этому!

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

11. "GCC 15 будет использовать стандарт C23 по умолчанию" +7 +/–

Сообщение от Аноним (11), 23-Ноя-24, 22:41

Ничего удивительного, в этом языке даже int + int является неопределенным поведением. Нам в 2024 ясно видна дикость этого, а вот палео-кодерам из палео-70-ых это казалось нормальной идеей.

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

28. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (31), 24-Ноя-24, 00:06

> int + int является неопределенным поведением
Воо, это вообще лютая дичь, я до сих пор не понимаю, КАК такое возможно в языке для системного программирования.

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

29. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (31), 24-Ноя-24, 00:08

П.с. а еще больше недоумеваю от тех УМВРщиков, которые в упор это не замечают.

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

33. "GCC 15 будет использовать стандарт C23 по умолчанию" +4 +/–

Сообщение от Аноним (32), 24-Ноя-24, 00:16

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

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

44. "GCC 15 будет использовать стандарт C23 по умолчанию" +2 +/–

Сообщение от Аноним (-), 24-Ноя-24, 00:41

> Потому что системный язык должен полагаться на то как происходит сложение на
> аппаратном уровне в конкретной системе, а не воротить абстракцию над абстракцией
> лишь бы все было везде одинаково. Кому надо одинаково идут на
> джаваскрипт зачем им Си?
Вон то на практике вело к дохреналиону багов, увы и ах. А абстракции что, как вон то алго не считай, а если ему надо не менее 32 битов для корректной работы - то хоть ты тресни, но ты или дашь эти 32 бита, или профачишь вычисления. В ряде случаев еще и с вулнами, отрицательными индексами массивов и прочими характерными факапами. И спасибо еще если это дамп памяти по сети или в эфир улетит. А то бывает и такое, heartbleed соврать не даст.

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

48. "GCC 15 будет использовать стандарт C23 по умолчанию" +4 +/–

Сообщение от mister_0 (?), 24-Ноя-24, 00:47

int a + int b <= int max
из этого условия можно вывести weakest predicate и проверить его до сложения
int max - int a => int b
если это условие не работает, то складывать не надо, будет страшный оверфлоу.
один if и тот сделать не могут, подавай им сразу новый язык, бороу чекер, безразмерную арифметику и прочее.

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

55. "GCC 15 будет использовать стандарт C23 по умолчанию" +1 +/–

Сообщение от Аноним (55), 24-Ноя-24, 01:11

> int a + int b <= int max
> из этого условия можно вывести weakest predicate и проверить его до сложения
> int max - int a => int b
Да, но...
1) Это лишняя операция.
2) Половина долбоклюев это забудет.
3) На практике в системном программировании порой нужны доступы конкретного размера, скажем к HW regs.
Ну то-есть железка может в принципе не поддерживать ничего кроме "доступ 32 бита шириной" и мне нафиг не вперся ваш int абстрактный, мне надо - доступ на шине 32 бита щириной.
> если это условие не работает, то складывать не надо, будет страшный оверфлоу.
> один if и тот сделать не могут, подавай им сразу новый язык,
> бороу чекер, безразмерную арифметику и прочее.
Это не халявно в рантайме и чревато глупыми багами. И выглядит как костыль.

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

62. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от mister_0 (?), 24-Ноя-24, 01:58

>Это не халявно в рантайме и чревато глупыми багами. И выглядит как костыль.
у тебя есть процессор и три регистра по 32 бита
ты загрузил в один регистр A 0x1000000
ты загрузил в другой регистр B 0x1000000
ты просишь процессор сложить A + B и записать в регистр C
у тебя не хватило бит и это оверфлоу
чтобы не было оверфлоу тебе надо что-то всё равно делать, это никогда не халявно.
за шины волноваться не стоит их там 100500 между регистром процессора и регистром девайса, там всё нормально будет.

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

96. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 07:16

> у тебя есть процессор и три регистра по 32 бита
Меня для начала колышет в системщине - делать доступы конкретного размера. А не абы какой от фонаря. Потому что часто надо при работе с железом, да и для предсказуемости математики самое то, чтобы как раз получать ГАРАНТИРОВАННЫЕ свойства.
> ты загрузил в один регистр A 0x1000000
> ты загрузил в другой регистр B 0x1000000
> ты просишь процессор сложить A + B и записать в регистр C
За 16-ричную математику этот аноним^W mister_0 получает твердую двойку! Ибо 0x2000000 прекрасно лезет в 32-битный регистр, сумма 25 битов всего.
И если я скажу

uint32_t something()
{
    uint32_t a = 0x1000000;
    uint32_t b = 0x1000000;
    return (a + b);
}

...то вот это как раз - ГАРАНТИРОВАННО сработает, как раз по причине диапазона, и более того компилер даже по этой аннотации проверить может - если вдруг нет. И выдать варнинг, между прочим.
А вот если я int в этом месте напишу - вот это будет залет. Ибо он и 16 битов может быть. При том на обычном компе это все прокатит. Но на каком-нибудь AVR голимом меня в таком коде будет ждать нефиговый сюрприз, если вдруг это не отловится почему-то. Когда вся математика отъедет нахрен. Заметьте, оптимизация вам тут все равно не светит. Если операция требует 25 битов, даже на атмеге компилер развернет 32-бит "этажерку" для этого. Да, это будет медленнее но это лучше чем напрочь некорректный счет в управляющей системе.
И это как раз причина int по возможности вообще не юзать. Хреново он в стандарте определен, и кто из програмеров всерьез уповает что это 16 битов? Большая часть кода подразумевает минимум 32. И конечно вытворяет черти что на авр каком.
Сериализовать int портабельно - это вообще отдельный вопрос. Т.е. IO по сети и с файлами это сразу задник. С uint32_t все сильно проше. Только с порядком байтов "в провод" определиться и - готово, мы знаем что всегда будет 4 байта.
> у тебя не хватило бит и это оверфлоу
Чтобы умничать по теме - в ней надо хоть что-то понимать, чтоли.
> чтобы не было оверфлоу тебе надо что-то всё равно делать, это никогда не халявно.
Или не надо. Как в вон том примере. Де факто там вообще будет нечто типа mov r5, #2000000h - ну или что там можно энному процу закодировать.
Т.е. де факто это скорее всего в том примере будет предвычесление и кода не будет вообще - только сам результат. А если это потом нигде не юзается - даже и этого не будет.
> за шины волноваться не стоит их там 100500 между регистром процессора и
> регистром девайса, там всё нормально будет.
На минуточку, есть еще mem-mapped периферия и проч. И вот оно довольно разборчивое на тему того какие туда доступы можно а какие нельзя. И давать лекции тому кто это все практикует - не рубя в топике - надо конкретно наглости набраться, "на уровне Кента" практически.

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

56. "GCC 15 будет использовать стандарт C23 по умолчанию" +3 +/–

Сообщение от Аноним (-), 24-Ноя-24, 01:16

> int max - int a => int b
Если значение "int a" отрицательное, будет переполнение при вычитание (underflow), которое тоже есть UB. В целом ваш коментарий показателен, типичный сишник не только не знает Си, но с умным лицом берется рассуждать о других языках.

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

59. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от mister_0 (?), 24-Ноя-24, 01:33

несомненно для отрицательных чисел нужно использовать min int, а ещё конечно не стоит забывать о представлении числа и в дополнительной форме отрицательных больше чем положительных на одно.
но идея вполне понятна, если ты боишься оверфлоу, то можешь вполне всё проверить.
эти проверки можно встроить или генерить автоматом, но они всё равно будут.
хочешь быстро используй специальную инструкцию
https://stackoverflow.com/questions/14523480/assembly-detect...
один чёрт всё равно придётся что-то придумать, что делать, если оверфлоу

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

64. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (64), 24-Ноя-24, 02:17

> эти проверки можно встроить или генерить автоматом, но они всё равно будут.
Вместо дорогой пред-проверки с явными сравнениями и несколькими ветками можно было бы использовать дешёвую пост-проверку регистра флагов, выражающуюся одним conditional jump'ом, вдобавок очень хорошо обрабатываемым branch predictor'ом. В C это невозможно сделать даже явно, а в современных языках это делается по умолчанию.

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

73. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (73), 24-Ноя-24, 04:04

Сначала проверь, что оба положительные, потом вычти одно из max int, сравни со вторым, потом уже можешь складывать.

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

118. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Bottle (?), 24-Ноя-24, 09:20

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

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

79. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Neon (??), 24-Ноя-24, 05:38

А простое сложение расползается кучей кода с кучей багов. Спасибо, не надо

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

91. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (91), 24-Ноя-24, 06:22

если a = -10, то при
int max - int a
будет оверфлоу
> один if и тот сделать не могут, подавай им сразу новый язык, бороу чекер, безразмерную арифметику и прочее.

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

122. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (122), 24-Ноя-24, 09:33

Когда мне нужно было решить задачу проверки на переполнение, я использовал intprops.h из gnulib. Как более удобная обёртка, что ли. Тоже в итоге там какие-то подобные проверки.

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

128. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (32), 24-Ноя-24, 09:55

Зачем тебе тогда си если ты собрался это проверять на каждом сложении? Чтобы побольше поторомозить? Ну так тебе уже сказали джаваскрипт твой выбор. Переполнение к слову не единственная проблема. И ты их проверять на каждом сложении .. устанешь.

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

105. "GCC 15 будет использовать стандарт C23 по умолчанию" +1 +/–

Сообщение от 21yosenior (?), 24-Ноя-24, 08:41

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

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

125. "GCC 15 будет использовать стандарт C23 по умолчанию" –1 +/–

Сообщение от Bottle (?), 24-Ноя-24, 09:43

Практика не показатель качества - выживают не самые сильные и умные, а самые адаптированные.
И в контексте рынка адаптация может означать широту поддержки и широкую популярность какой-то ОС, написанной на копроязычке (привет, Юникс) для PDP-11.

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

130. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (32), 24-Ноя-24, 09:57

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

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

46. "GCC 15 будет использовать стандарт C23 по умолчанию" +2 +/–

Сообщение от Аноним (-), 24-Ноя-24, 00:45

> Потому что системный язык должен полагаться на то как происходит сложение
> на аппаратном уровне в конкретной системе
Угу, именно поэтому они это не implementation-defined, не хотя бы unspecified, а вот сразу UB!
Что бы когда ты писал код, то как он будет работать было именно ХЗ, в зависимости от платформы, железа, флагов, степени безумия разраба компилятора, которые может просто выкинуть твой код нафиг с обоснование "не, ну не бывает же UB в нормальном коде".

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

54. "GCC 15 будет использовать стандарт C23 по умолчанию" –2 +/–

Сообщение от анон (?), 24-Ноя-24, 01:10

Такова плата за генерацию эффективного кода. Никто же не заставляет использовать именно Си

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

69. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 02:50

> Такова плата за генерацию эффективного кода.
Так ведь всё с точностью до наоборот. В Си надо обложить код if`ами чтобы не получить UB, но если у тебя модульная арифметика (в том числе знаковая) тогда на это можно положиться и писать эффективный код.

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

74. "GCC 15 будет использовать стандарт C23 по умолчанию" +2 +/–

Сообщение от Bottle (?), 24-Ноя-24, 04:10

О дааа! Тот самый эффективный код на Си, известный своими утечками памяти. А то, что указатели не обладают строгостью, как в Фортране, это мы конечно умолчим. И то, что "швитой штандарт" разрешает любым переменным занимать хоть 64 бита, лишь бы преодолевали минимальную границу длины от стандарта. Да, очень эффективное управление памятью для переменных вида int и float. Всего лишь в два-четыре раза больше положенного.

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

80. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Neon (??), 24-Ноя-24, 05:39

Это называется халтура. На от@бись

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

106. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от 21yosenior (?), 24-Ноя-24, 08:44

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

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

120. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (73), 24-Ноя-24, 09:31

Аноним написал много латинских слов, и думает, что написал что-то умное.
А на самом деле, implementation-defined, unspecified и undefined, это буквально одно и то же. Что конкретно скрывается за UB, должно быть задокументировано в документации к компилятору.

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

47. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 00:46

Ну давай, расскажи мне как ты собрался из Си "полагаться на то как происходит сложение на аппаратном уровне" если переполнение int`ов есть undefined behavior а не implementation-defined behavior.

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

78. "GCC 15 будет использовать стандарт C23 по умолчанию" +1 +/–

Сообщение от Neon (??), 24-Ноя-24, 05:35

Пусть на ассемблере кодят, раз им нужно сложение на аппаратном уровне в конкретной системе. Язык высокого уровня уже по любому абстракция

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

90. "GCC 15 будет использовать стандарт C23 по умолчанию" +1 +/–

Сообщение от morphe (?), 24-Ноя-24, 06:13

> Потому что системный язык должен полагаться на то как происходит сложение на аппаратном уровне в конкретной системе, а не воротить абстракцию над абстракцией лишь бы все было везде одинаково.
Вот только всё современное железо реализует это как two's complement, и сложение везде переполняется. (Кроме каких-нибудь мейнфреймов на system z с binary-coded-decimals, но даже там C реализован не через это) Rust же гарантирует что сложение переполняется всегда, потому что стандартные числа в Rust всегда two's complement. (Что на каких-то абстрактных платформах может потребовать софтверной реализации, но таких фактически не существует)
А в сях стандарт написан так, что сложение может происходить на абаках, а потому переполнение - undefined behavior, иначе говоря компилятор в праве оптимизировать код так, будто переполнения никогда не произойдут НА ЛЮБОЙ ПЛАТФОРМЕ.

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

111. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (111), 24-Ноя-24, 08:54

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

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

104. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от 21yosenior (?), 24-Ноя-24, 08:39

Просто они знают, что ub является переполнение, а не сложение. Поэтому у них всё работает.

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

42. "GCC 15 будет использовать стандарт C23 по умолчанию" –1 +/–

Сообщение от mister_0 (?), 24-Ноя-24, 00:37

ну так ты проверь перед сложением или можешь после сложения в регистр flags посмотреть, там есть бит переполнения.
а ещё есть люди которые рапэраунд с оверфлоу путают

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

49. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (49), 24-Ноя-24, 00:48

> или можешь после сложения в регистр flags посмотреть
в С?

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

50. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от mister_0 (?), 24-Ноя-24, 00:53

ну придётся ассемблерную вставку сделать.

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

53. "GCC 15 будет использовать стандарт C23 по умолчанию" +1 +/–

Сообщение от Аноним (-), 24-Ноя-24, 01:04

> ну придётся ассемблерную вставку сделать.
А ничего что на сях мы писали - чтобы портабельно было, м?!

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

123. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (73), 24-Ноя-24, 09:36

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

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

127. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (73), 24-Ноя-24, 09:49

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

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

81. "GCC 15 будет использовать стандарт C23 по умолчанию" +1 +/–

Сообщение от Neon (??), 24-Ноя-24, 05:40

А на хрена тогда С нужен ? Если нужно сразу на ассемблере фигачить

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

51. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от mister_0 (?), 24-Ноя-24, 00:55

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

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

65. "GCC 15 будет использовать стандарт C23 по умолчанию" +1 +/–

Сообщение от Аноним (64), 24-Ноя-24, 02:19

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

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

108. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от 21yosenior (?), 24-Ноя-24, 08:48

Пистон написан на си, поэтому там ситуация таже самая. Раст компилируется си компилятором, поэтому ситуация снова такая же. Хоть паскалик бы в пример привёл - не настолько позорно было бы.

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

107. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от 21yosenior (?), 24-Ноя-24, 08:45

В си. __builtin_*_overflow() - 1000 лет есть.

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

119. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от 21yosenior (?), 24-Ноя-24, 09:21

Нет, похоже всё ещё хуже - там в новости написано "Добавлена поддержка заголовочных файлов <stdckdint.h>". Это даже в стандарте теперь есть, но почему-то эксперты говорят "в си нет способа".

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

52. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 01:04

> ну так ты проверь перед сложением или можешь после сложения в регистр
> flags посмотреть, там есть бит переполнения.
В сях нет стандартного способа посмотерть флаги, внезапно.
> а ещё есть люди которые рапэраунд с оверфлоу путают
Wrapround определен и гарантирован только для unsigned, если что.

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

82. "GCC 15 будет использовать стандарт C23 по умолчанию" –1 +/–

Сообщение от Neon (??), 24-Ноя-24, 05:41

> В сях нет стандартного способа посмотерть флаги, внезапно.
Такой системный язык))). Близкий к аппаратуре

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

97. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 07:28

>> В сях нет стандартного способа посмотерть флаги, внезапно.
> Такой системный язык))). Близкий к аппаратуре
Внезапно он еще и про портабельность. А имплементация флагов у разных процов - довольно разная бывает. Так что - ограничения жанра, скажем так.
В парадигмах C вообще возможны как таковые только mem-mapped доступы. Если нечто не отмаплено в память - ну, этого нет. На память об этом вся современная периферия как раз mem mapped, а всякие io пространства - легаси. Заодно mem mapped железки и DMA удобны, чего уж там. Самый лучший код - это его отсутствие!

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

124. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (111), 24-Ноя-24, 09:40

> В парадигмах C вообще возможны как таковые только mem-mapped доступы.
Ну, у C есть ещё стандартизированные* расширения из ISO/IEC TR 18037. Среди которых named address spaces** и iohw.h.
Флеш-память и EEPROM в AVR не отмаплены на адресное пространство RAM и требуют других инструкций, но с расширением компилятор сам их будет вставлять.
Хоба:
__eeprom volatile unsigned char ee_var = 0xff; // IAR
const __flash int array[] = { 3, 5, 7, 11, 13, 17, 19 }; // GCC
С одной стороны, всё-таки расширение, а не чистый язык. А с другой стороны, на расширение аж стандарт есть, это не линуксовые гнутости. Если бы отдельные пространства прижились, то расширение бы и в язык перекочевало.
* Стандартность оказалась достаточно весома, чтобы GCC их не реализовывал в C++
** https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html

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

112. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от 21yosenior (?), 24-Ноя-24, 08:55

> В сях нет стандартного способа посмотерть флаги, внезапно.
Не позорься - написал выше этот способ.
> Wrapround определен и гарантирован только для unsigned, если что.
Опять же, нужно меньше позориться. ++*(unsigned*)&int_var - переполняй сколько хочешь.

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

103. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от 21yosenior (?), 24-Ноя-24, 08:38

Судя по всему решение хорошее. Как иначе объяснить, что весь софт написан на этой дикости, а на чём-то ином не аписано ничего.

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

110. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (110), 24-Ноя-24, 08:54

Миллионы мух не могут ошибаться, как тут любят говорить.

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

116. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от 21yosenior (?), 24-Ноя-24, 09:06

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

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

12. "GCC 15 будет использовать стандарт C23 по умолчанию" +1 +/–

Сообщение от Аноним (12), 23-Ноя-24, 22:46

Значит ли это, что gcc 15 будет поддерживать стандарт c23 ПОЛНОСТЬЮ?

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

15. "GCC 15 будет использовать стандарт C23 по умолчанию" +3 +/–

Сообщение от Маковод (?), 23-Ноя-24, 23:02

Всё это ерунда, есть же православный ANSI C (C89). Всё остальное — ненужный реверс инжиниринг с синтаксическим сахаром.

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

16. "GCC 15 будет использовать стандарт C23 по умолчанию" +4 +/–

Сообщение от Маковод (?), 23-Ноя-24, 23:03

Овер инжиниринг* (будь проклята автозамена)

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

34. "GCC 15 будет использовать стандарт C23 по умолчанию" –1 +/–

Сообщение от Аноним (32), 24-Ноя-24, 00:19

Сахар это язык zig. Си это та ложка дегтя.

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

41. "GCC 15 будет использовать стандарт C23 по умолчанию" +2 +/–

Сообщение от Аноним (-), 24-Ноя-24, 00:34

> Всё это ерунда, есть же православный ANSI C (C89). Всё остальное —
> ненужный реверс инжиниринг с синтаксическим сахаром.
Вот ты на нем и прогай. А я меньше чем на C99 в принципе не согласен, а лучше минимум 11, ибо делать из г-на и палок аналог static assert'а - ну такое себе.

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

18. "GCC 15 будет использовать стандарт C23 по умолчанию" –2 +/–

Сообщение от nc (ok), 23-Ноя-24, 23:26

Расширения GNU давно пора принимать в стандарты С и С++. Простые и полезные идеи, уже давно реализованные и многократно проверенные.
Единственное чего не хватает - расширения __declspec(property) в С++, которое есть в msvc и clang, но нет в gcc.

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

38. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 00:23

llvm не лучше? обоснуйте

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

115. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от 21yosenior (?), 24-Ноя-24, 09:04

Хуже.
```
int f(int* p, int a) { p = __builtin_assume_aligned(p, a); }
```

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

40. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 00:31

> атрибут [[noreturn]] позволяет указать, что функция не возвращает значений
Вообще-то он указывает что функция никогда не возвращается. Скажем main в фирмвари - возвращаться некуда и его можно задекларить так (экономит немного кода в прологе функции).

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

58. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (58), 24-Ноя-24, 01:20

14 версия при сборке пакетов ругалась на указатели, 15 будет ругаться если код не той версии. Страшно представить на что 16 версия ругаться будет.

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

70. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от мяв (?), 24-Ноя-24, 02:59

что-то фигня какая-то с auto..
auto myNum = superCalculator(2,2);
и иди гадай, кого там возвращает твоя функция.
а потом твой друг пойдет гадать и лазать в соседнем файле, когда откроет код .. псоле чего окажется, что эту фцнкцию где-то там по дороге перекрыли/перепилили/вовсе другой файл включили и она тперь возвращает int, вместо uint :|
зачем вообще такое добавлять в язык со сторой типизацией?
ну, серьезно, это ж лол какой-то.
послезавтра эта функция будет char* возвращать. и я, вместо жалобы на неправельный тип в декларации, увижу 100500 жалоб в черт пойми, каких частях кода.
а auto молча станет char*.

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

71. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от мяв (?), 24-Ноя-24, 03:00

я ж правильно логику работы auto поняла?

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

84. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Neon (??), 24-Ноя-24, 05:43

Какие проблемы ? Смотрим объявление функции. В современных IDE это автоматом подсвечивается при наведении на функцию

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

86. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Илья (??), 24-Ноя-24, 05:48

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

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

99. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 07:45

> что-то фигня какая-то с auto..
> auto myNum = superCalculator(2,2);
Да вот блин да, научились у некоторых - а конкретно плюсеров. Но порой таки - удобно.
Прикинь если есть несколько compound types - например struct, и мы переменную декларим в небольшой области видимости, как auto, и там может быть или 1 подвид, или другой, и нам не хочется греть мозг какой именно - ибо код дальше корректно рюхал оба. В таком случае оно выходит довольно элегантно. И как минимум в плбсах катит. А тут... посмотрим, посмотрим.
> и иди гадай, кого там возвращает твоя функция.
Вообще в ide-like это просто go to declaration (как правило шорткат). Хоть конечно и лишний клац.
> по дороге перекрыли/перепилили/вовсе другой файл включили и она тперь возвращает int,
> вместо uint :|
Вообще я не очень понимаю зачем auto в C/C++ совать. Туда же примерно и автоматический вывод типов без явного указания. Это -1 барьер на пути багов. Лишняя аннотация намерений позволяет поймать баг если намерения все же обломались.
> зачем вообще такое добавлять в язык со сторой типизацией?
C никогда не был с вообще совсем строгой. И позволяет оверрайды. Можно приказать считать апельсины лимонами, сделав явный каст. Что будет дальше - на совести програмера, ессно.
> а auto молча станет char*.
Но есть вариант когда код был готов сожрать и то и другое. А с Generic такой вариант еще и "популяризован" фичой в конструкции яп.
Си вообще забавная штука. Вроде низкоуровневый, но функция на самом деле может и получить и вернуть даже struct. Или struct'ы можно присваивать друг другу, однотипные конечно (технически это будет вызов memcpy - кодом выданным компилером на такое действо). А в struct можно еще и допустим указатель на функцию загнать - и тогда получится ну разве что не C++ с "методами", но - нечто достаточно похожее. Ибо struct.myFunc(arg) - будет вполне валидной конструкцией так то. Но поскольку это все же не C++ то это имеет свои лимиты.

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

113. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Бывалый Смузихлёб (ok), 24-Ноя-24, 08:57

Зато, как славно показали себя иные адепты строгой и явной типизации и отсутствия такого у того же ЖС вот то ли дело сишечка
Стоило лишь в некоторые ЯП подвезти auto. Наворачивали за обе щёки и обмазывали вообще всё до чего могли дотянуться, а не использовали ранее - тупо потому что такой возможности не было

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

77. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (77), 24-Ноя-24, 05:35

Зачем снова новый тип char8_t, если уже есть char и unsigned char. Более того есть еще stdint.h где есть int8_t и uint8_t. Почему?

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

85. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Neon (??), 24-Ноя-24, 05:44

Почему "Ы" ???  Чтоб никто не догадался!)

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

87. "GCC 15 будет использовать стандарт C23 по умолчанию" –1 +/–

Сообщение от Аноним (87), 24-Ноя-24, 05:50

> Удалена возможность определения функций в стиле K&R C, используемом до принятия спецификации ANSI C и описанном в книге "The C Programming Language" Кернигана и Ритчи.
Так это уже не тот язык С, который придумали его изобретатели Брайан Керниган и Деннис Ритчи. Это совсем совсем другой язык "С23" и т.д. и т.п. А значит, можно использовать старый стандарт 89 года, с оговоркой, что это настоящий язык С.

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

88. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (87), 24-Ноя-24, 05:53

Оригинальный язык С описан в книге "The C Programming Language" Кернигана и Ритчи. Все остальное я могу с полным правом игнорировать. Отныне все мои проекты будут базироваться исключительно на книге "The C Programming Language".

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

89. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (87), 24-Ноя-24, 06:01

> указания имён неиспользуемых параметров при определении функций (как в C++)
> определения атрибутов как в С++
Также языком С++ лично я считаю язык представленный в книге The C++ Programming Language (1st edition). Все остальное - это выдумки, и я могу их с полным правом игнорировать.

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

117. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (-), 24-Ноя-24, 09:17

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

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

92. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от ijuij (?), 24-Ноя-24, 06:35

> Удалена возможность определения функций в стиле K&R C
Это меня огорчает, у меня есть ещё код в подобном стиле!

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

93. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от ijuij (?), 24-Ноя-24, 06:46

А так мне все нововведения нравятся, и особенно хочу отметить это:
> Добавлены типы "_BitInt (N)" и "unsigned _BitInt (N))" для определения целых чисел с указанным числом битов
🔝

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

101. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (101), 24-Ноя-24, 07:47

Мммм. Как же мне не хватало переменных длиной 3, 7, 11 бит

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

109. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от Аноним (110), 24-Ноя-24, 08:53

Это ж какой простор для UB!
Ну и вообще, полностью идёт вразрез с идеей сишки. Всякие char/int реализуются аппаратно by design, а это-то как?

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

114. "GCC 15 будет использовать стандарт C23 по умолчанию" +/–

Сообщение от ijuij (?), 24-Ноя-24, 09:00

> а это-то как?
Там внедрено много кода, взгляни на коммиты в GCC:
https://github.com/search?q=repo%3Agcc-mirror%2Fgc...

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "GCC 15 будет использовать стандарт C23 по умолчанию"	+14 +/–
Сообщение от ДаНуНафиг (?), 23-Ноя-24, 21:46
Ну надо же, bool/true/false подвезли! Я дожил до этого момента!
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "GCC 15 будет использовать стандарт C23 по умолчанию"	+3 +/–
	Сообщение от Аноним (8), 23-Ноя-24, 22:32
	А те, кому реально это было нужно — не ждали и использовали <stdbool.h>, начиная с C99…
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "GCC 15 будет использовать стандарт C23 по умолчанию"	+5 +/–
	Сообщение от Анон28679234 (?), 24-Ноя-24, 02:39
	Вообще довольно странно рассуждать о примитивных типах как о "реально нужных" или ненужных При определенной степени ментальных упражнений можно даже ассемблер называть синтаксическим сахаром для электроцепи, однако я не вижу очереди желающих написать себе сайт с помощью паяльника
	Ответить \| Правка \| Наверх \| Cообщить модератору


	129. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Герострат (?), 24-Ноя-24, 09:55
	> однако я не вижу очереди желающих написать себе сайт с помощью паяльника Судя по современному вебу, сайты только так и пишут: вставляют паяльник в обезьяну и понеслась.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	72. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 03:35
	> Ну надо же, bool/true/false подвезли! Я дожил до этого момента! Это еще что! Как тебе такое Элон Маск?! > Появилась поддержка использования спецификатора constexpr для определения объектов. А вот тут... > Добавлена поддержка префиксов "0b" и "0B" для указания целых значений в двоичной форме ...всем микроконтроллерщикам радоваться полчаса!
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	121. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (121), 24-Ноя-24, 09:32
	"Хочу смеяться пять минут!" ©
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. Скрыто модератором	+2 +/–
Сообщение от Аноним (2), 23-Ноя-24, 21:58
Как-то всё равно. Мой мак с macOS давно слез с Гэ-Цэ-Цэ, у которого, откровенно говоря, лицензия, которая выгодна только корпорациям.
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. Скрыто модератором	+5 +/–
	Сообщение от Блюститель лицензий (?), 23-Ноя-24, 22:03
	Сидеть на маке и жаловаться на лицензию, "выгодную корпорациям" - это какой-то новый уровень.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. Скрыто модератором	+4 +/–
	Сообщение от Маковод (?), 23-Ноя-24, 22:19
	Финн Линус же сидит (как и большая часть кернел девелоперов).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. Скрыто модератором	–2 +/–
	Сообщение от Аноним (8), 23-Ноя-24, 22:38
	> лицензия, которая выгодна только корпорациям. Толсто же. GCC распространяется по лицензии GPLv3+, которая заставляет раскрывать код и делиться патентами. Clang из макоси распространяется по лицензии Apache 2.0, не накладывающей никаких ограничений на закрытие кода. Х–м–м, и какая же из них «выгодна только корпорациям»? Такой сложный вопрос (нет).
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	14. Скрыто модератором	+/–
	Сообщение от Маковод (?), 23-Ноя-24, 23:00
	> Х–м–м, и какая же из них «выгодна только корпорациям»? Любая, которая позволяет делать форки и потом коммерциализировать этот софт, который написан бесплатной мартышкой, уверовавшей в шваботку.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. Скрыто модератором	+/–
	Сообщение от YetAnotherOnanym (ok), 23-Ноя-24, 23:33
	> какая же из них «выгодна только корпорациям»? Та, которая заставит маленький стартап выложить всё на блюдечке с голубой каёмочкой забесплатно. Для Безоса и ему подобных.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	31. Скрыто модератором	–1 +/–
	Сообщение от Аноним (31), 24-Ноя-24, 00:11
	> Как-то всё равно. Мой мак с macOS давно слез с Гэ-Цэ-Цэ, у > которого, откровенно говоря, лицензия, которая выгодна только корпорациям. Два чая адеквату. Вся эта GPL — типичный троянский конь, где под прикрытием "свободы" корпорасты получают почти даром готовые продукты и бесплатную рабочую силу.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору

6. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (6), 23-Ноя-24, 22:25
>Структуры, объединения и перечисления разрешено определять более одного раза в одной области видимости с одним и тем же содержимым и повторяющимся тегом. а это зачем?
Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от bircoph (ok), 23-Ноя-24, 22:35
	Чтоб меньше конфликтов было при всяких #include и inline.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "GCC 15 будет использовать стандарт C23 по умолчанию"	–3 +/–
	Сообщение от Аноним (6), 23-Ноя-24, 23:23
	> Чтоб меньше конфликтов было при всяких #include и inline. И как 50 лет жили без этого.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "GCC 15 будет использовать стандарт C23 по умолчанию"	+5 +/–
	Сообщение от Аноним (32), 24-Ноя-24, 00:14
	С матами и постоянными переименованиями всего и вся лишь бы этот комп-депилятор перестал жаловаться, а уже начал комп-депилировать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "GCC 15 будет использовать стандарт C23 по умолчанию"	+3 +/–
	Сообщение от Аноним (39), 24-Ноя-24, 00:25
	Жили же тысячи лет в пещерах и ничего.
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	95. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 06:55
	>> Чтоб меньше конфликтов было при всяких #include и inline. > И как 50 лет жили без этого. Ну, как, как, городили костыли типа #ifndef HAVE_WTF_H #define HAVE_WTF_H ...(основная тушка)... #endif
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	126. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (6), 24-Ноя-24, 09:44
	Теперь не будут?
	Ответить \| Правка \| Наверх \| Cообщить модератору

7. "GCC 15 будет использовать стандарт C23 по умолчанию"	+4 +/–
Сообщение от Аноним (7), 23-Ноя-24, 22:30
> Вызов функции realloc() с нулевым размером переведён в разряд неопределённого поведения. Нужно больше неопределённого поведения! Потом, когда вылезут очередные уязвимости из-за работы с памятью, можно будет с уверенностью утверждать, что где-то ещё оптимизатор смог ускорить работу на 0.01% благодаря этому!
Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "GCC 15 будет использовать стандарт C23 по умолчанию"	+7 +/–
	Сообщение от Аноним (11), 23-Ноя-24, 22:41
	Ничего удивительного, в этом языке даже int + int является неопределенным поведением. Нам в 2024 ясно видна дикость этого, а вот палео-кодерам из палео-70-ых это казалось нормальной идеей.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (31), 24-Ноя-24, 00:06
	> int + int является неопределенным поведением Воо, это вообще лютая дичь, я до сих пор не понимаю, КАК такое возможно в языке для системного программирования.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (31), 24-Ноя-24, 00:08
	П.с. а еще больше недоумеваю от тех УМВРщиков, которые в упор это не замечают.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "GCC 15 будет использовать стандарт C23 по умолчанию"	+4 +/–
	Сообщение от Аноним (32), 24-Ноя-24, 00:16
	Потому что системный язык должен полагаться на то как происходит сложение на аппаратном уровне в конкретной системе, а не воротить абстракцию над абстракцией лишь бы все было везде одинаково. Кому надо одинаково идут на джаваскрипт зачем им Си?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 00:41
	> Потому что системный язык должен полагаться на то как происходит сложение на > аппаратном уровне в конкретной системе, а не воротить абстракцию над абстракцией > лишь бы все было везде одинаково. Кому надо одинаково идут на > джаваскрипт зачем им Си? Вон то на практике вело к дохреналиону багов, увы и ах. А абстракции что, как вон то алго не считай, а если ему надо не менее 32 битов для корректной работы - то хоть ты тресни, но ты или дашь эти 32 бита, или профачишь вычисления. В ряде случаев еще и с вулнами, отрицательными индексами массивов и прочими характерными факапами. И спасибо еще если это дамп памяти по сети или в эфир улетит. А то бывает и такое, heartbleed соврать не даст.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "GCC 15 будет использовать стандарт C23 по умолчанию"	+4 +/–
	Сообщение от mister_0 (?), 24-Ноя-24, 00:47
	int a + int b <= int max из этого условия можно вывести weakest predicate и проверить его до сложения int max - int a => int b если это условие не работает, то складывать не надо, будет страшный оверфлоу. один if и тот сделать не могут, подавай им сразу новый язык, бороу чекер, безразмерную арифметику и прочее.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (55), 24-Ноя-24, 01:11
	> int a + int b <= int max > из этого условия можно вывести weakest predicate и проверить его до сложения > int max - int a => int b Да, но... 1) Это лишняя операция. 2) Половина долбоклюев это забудет. 3) На практике в системном программировании порой нужны доступы конкретного размера, скажем к HW regs. Ну то-есть железка может в принципе не поддерживать ничего кроме "доступ 32 бита шириной" и мне нафиг не вперся ваш int абстрактный, мне надо - доступ на шине 32 бита щириной. > если это условие не работает, то складывать не надо, будет страшный оверфлоу. > один if и тот сделать не могут, подавай им сразу новый язык, > бороу чекер, безразмерную арифметику и прочее. Это не халявно в рантайме и чревато глупыми багами. И выглядит как костыль.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от mister_0 (?), 24-Ноя-24, 01:58
	>Это не халявно в рантайме и чревато глупыми багами. И выглядит как костыль. у тебя есть процессор и три регистра по 32 бита ты загрузил в один регистр A 0x1000000 ты загрузил в другой регистр B 0x1000000 ты просишь процессор сложить A + B и записать в регистр C у тебя не хватило бит и это оверфлоу чтобы не было оверфлоу тебе надо что-то всё равно делать, это никогда не халявно. за шины волноваться не стоит их там 100500 между регистром процессора и регистром девайса, там всё нормально будет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	96. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 07:16
	> у тебя есть процессор и три регистра по 32 бита Меня для начала колышет в системщине - делать доступы конкретного размера. А не абы какой от фонаря. Потому что часто надо при работе с железом, да и для предсказуемости математики самое то, чтобы как раз получать ГАРАНТИРОВАННЫЕ свойства. > ты загрузил в один регистр A 0x1000000 > ты загрузил в другой регистр B 0x1000000 > ты просишь процессор сложить A + B и записать в регистр C За 16-ричную математику этот аноним^W mister_0 получает твердую двойку! Ибо 0x2000000 прекрасно лезет в 32-битный регистр, сумма 25 битов всего. И если я скажу uint32_t something() { uint32_t a = 0x1000000; uint32_t b = 0x1000000; return (a + b); } ...то вот это как раз - ГАРАНТИРОВАННО сработает, как раз по причине диапазона, и более того компилер даже по этой аннотации проверить может - если вдруг нет. И выдать варнинг, между прочим. А вот если я int в этом месте напишу - вот это будет залет. Ибо он и 16 битов может быть. При том на обычном компе это все прокатит. Но на каком-нибудь AVR голимом меня в таком коде будет ждать нефиговый сюрприз, если вдруг это не отловится почему-то. Когда вся математика отъедет нахрен. Заметьте, оптимизация вам тут все равно не светит. Если операция требует 25 битов, даже на атмеге компилер развернет 32-бит "этажерку" для этого. Да, это будет медленнее но это лучше чем напрочь некорректный счет в управляющей системе. И это как раз причина int по возможности вообще не юзать. Хреново он в стандарте определен, и кто из програмеров всерьез уповает что это 16 битов? Большая часть кода подразумевает минимум 32. И конечно вытворяет черти что на авр каком. Сериализовать int портабельно - это вообще отдельный вопрос. Т.е. IO по сети и с файлами это сразу задник. С uint32_t все сильно проше. Только с порядком байтов "в провод" определиться и - готово, мы знаем что всегда будет 4 байта. > у тебя не хватило бит и это оверфлоу Чтобы умничать по теме - в ней надо хоть что-то понимать, чтоли. > чтобы не было оверфлоу тебе надо что-то всё равно делать, это никогда не халявно. Или не надо. Как в вон том примере. Де факто там вообще будет нечто типа mov r5, #2000000h - ну или что там можно энному процу закодировать. Т.е. де факто это скорее всего в том примере будет предвычесление и кода не будет вообще - только сам результат. А если это потом нигде не юзается - даже и этого не будет. > за шины волноваться не стоит их там 100500 между регистром процессора и > регистром девайса, там всё нормально будет. На минуточку, есть еще mem-mapped периферия и проч. И вот оно довольно разборчивое на тему того какие туда доступы можно а какие нельзя. И давать лекции тому кто это все практикует - не рубя в топике - надо конкретно наглости набраться, "на уровне Кента" практически.
	Ответить \| Правка \| Наверх \| Cообщить модератору