- Ну надо же, bool true false подвезли Я дожил до этого момента , ДаНуНафиг (?), 21:46 , 23-Ноя-24 (1) +35 [^]
- А те, кому реально это было нужно 8212 не ждали и использовали stdbool h , н, Аноним (8), 22:32 , 23-Ноя-24 (8) +12 [^]
- Вообще довольно странно рассуждать о примитивных типах как о реально нужных ил, Анон28679234 (?), 02:39 , 24-Ноя-24 (68) +14 [^]
- Поверьте налепив сверху на ассемблер макросов можно с легкостью слабать любой са, Аноним (176), 10:17 , 24-Ноя-24 (132)
- зачем это декаденство любой сайт можно с легкостью спаять, Аноним (174), 13:55 , 24-Ноя-24 (174) +3
- Ассемблер это и есть набор макросов над набором инструкций процессора А вот если, Аноним (184), 15:06 , 24-Ноя-24 (184) –1
- На сях микросервис может как на go быть, если правильную либу взять Т е полстр, Аноним (-), 14:55 , 26-Ноя-24 (327)
> Поверьте налепив сверху на ассемблер макросов можно с легкостью слабать любой сайт )) На сях микросервис может как на go быть, если правильную либу взять. Т.е. полстранички текста. Скажем см https://lwan.ws - hello world менее чем полстраницы может быть. И это на сях. После чего он еще и в топе любого тематичного бенча отвиснет. А покажете на асме такое? :)
- Это еще что Как тебе такое Элон Маск А вот тут всем микроконтроллерщикам, Аноним (-), 03:35 , 24-Ноя-24 (72) +1
- Хочу смеяться пять минут , Аноним (48), 09:32 , 24-Ноя-24 (121) +3
- Ну, кстати, 0b, 0B и b были вполне логичны изначально А вот true и false излиш, Тот_Самый_Анонимус_ (?), 11:46 , 24-Ноя-24 (146) –3
- не, ну как только в процессорах появятся true и false , а не jz, так сразу пу, нах. (?), 11:49 , 24-Ноя-24 (147) +4
- Наличие или отсутствие jz в конкретном процессоре - вообще не гарантировано А, Аноним (-), 15:22 , 24-Ноя-24 (186)
- лолшта Процессор без условного перехода - еще не изобрели А когда изобретут, в, нах. (?), 16:15 , 24-Ноя-24 (197) +2
- Как именно реализованы у конкретного проца условные переходы и какие там условия, Аноним (-), 16:39 , 24-Ноя-24 (206) –2
- но проца с истиными true false ты конечно же не покажешь Проца без jz полагаю т, нах. (?), 18:50 , 24-Ноя-24 (236) +1
- А я думал ты шутишь так В процессорах нет типов, там и nullptr нет и enum, мног, Аноним (244), 21:07 , 24-Ноя-24 (244)
- Он у меня вообще непригоден для условных переходов, его только сравнить с другим, нах. (?), 10:15 , 25-Ноя-24 (252)
- В процессорах есть типы, среди которых nullptr_t, ну и ну А стандарт говорит о к, Аноним (244), 18:17 , 25-Ноя-24 (296)
- [.... слишком большой тред, остальное см. в режиме смотреть все |+ ] (298)!!!!!
- то есть, на твоих процессорах отсутствует реализация IEEE 754 хреново, бро , arisu (ok), 18:44 , 28-Ноя-24 (355)
> У меня нет процессоров с минуснулем который можно
> использовать как условие.то есть, на твоих процессорах отсутствует реализация IEEE 754? хреново, бро.
- RISC V Там совмещённые команды BEQ BNE BLT BGE, см https habr com ru article, Совершенно другой аноним (?), 12:32 , 25-Ноя-24 (266) +1
- На минуточку вся цифровая логика это 1 и 0, true и false И что такое 5 если я, Аноним (-), 18:34 , 25-Ноя-24 (297)
- эвона как отстутствие нормального булевого типа 8212 это антиграбли ну поду, arisu (ok), 18:49 , 28-Ноя-24 (356)
> Все что не 0 является true в булеановской логике. В целом
> - это некий набор антиграбель.эвона как. отстутствие нормального булевого типа — это антиграбли. ну подумаешь, написал `(a & b)` а не `(a && b)` — компилятор и не квакнул. в нормальном языке побитовые операции (и вообще арифметика) к булам неприменимы. и наоборот: булевы операции неприменимы к другим типам. но это, конечно, грабли. антиграбли — это молча слопать любую ерунду, потому что вместо нормальной системы типов завезли фэйк.
- Думаю что статический анализатор это таки отловит Это все прекрасно - кроме того, Аноним (357), 19:06 , 28-Ноя-24 (358)
> эвона как. отстутствие нормального булевого типа — это антиграбли. ну подумаешь,
> написал `(a & b)` а не `(a && b)` — компилятор и не квакнул.Думаю что статический анализатор это таки отловит. > в нормальном языке побитовые операции (и вообще арифметика) к булам неприменимы. и
> наоборот: булевы операции неприменимы к другим типам. но это, конечно, грабли.
> антиграбли — это молча слопать любую ерунду, потому что вместо нормальной
> системы типов завезли фэйк. Это все прекрасно - кроме того что эти языки не с нами там где все вон то реально надо было. И о чем мы тут вещаем? А так да, сишка несколько педальный, зато эта педальность при случае позволяет все же сделать вон то - если очень надо. А не упереться рогом жестко в ограничения. - [.... слишком большой тред, остальное см. в режиме смотреть все |+ ] (360)!!!
- ЧСХ я ими и пользовался уже лет 10 Просто как GNU Extension Все равно вон та ф, Аноним (181), 14:52 , 24-Ноя-24 (181) –2
- Микроконтроллерщики уже на C , Аноним (167), 13:15 , 24-Ноя-24 (167) –1
- Пятьдесят джва года ждал Как в DOS в своё время не хватало, всякие железки в пор, Аноним (237), 18:51 , 24-Ноя-24 (237) –1
- так и запишем - восьмеричная система счисления тебе не далась а начинал бы не с, нах. (?), 11:47 , 25-Ноя-24 (257)
- Так и запишем 8212 ты совершенно не понял, о чём речь , Аноним (237), 12:14 , 25-Ноя-24 (262)
- В DOS и x86 была принята шестнадцатеричная , Аноним (87), 12:19 , 25-Ноя-24 (264)
- Ну попробуй программировать битовые поля в хардварных регистрах в восьмеричной с, Аноним (-), 18:51 , 25-Ноя-24 (301)
- вы так дождетесь и вам ещё True-1 и True-2 подвезут, ffsdmad (ok), 08:15 , 26-Ноя-24 (315) +1
вы так дождетесь и вам ещё True-1 и True-2 подвезут
- Скрыто модератором, Аноним (203), 21:58 , 23-Ноя-24 (2) [---]
- а это зачем , Аноним (6), 22:25 , 23-Ноя-24 (6)
- Нужно больше неопределённого поведения Потом, когда вылезут очередные уязвимост, Аноним (7), 22:30 , 23-Ноя-24 (7) +10 [^]
- Ничего удивительного, в этом языке даже int int является неопределенным поведе, Аноним (6), 22:41 , 23-Ноя-24 (11) +8 [^]
- Воо, это вообще лютая дичь, я до сих пор не понимаю, КАК такое возможно в языке , Аноним (18), 00:06 , 24-Ноя-24 (28)
- П с а еще больше недоумеваю от тех УМВРщиков, которые в упор это не замечают , Аноним (18), 00:08 , 24-Ноя-24 (29)
- Потому что системный язык должен полагаться на то как происходит сложение на апп, Аноним (12), 00:16 , 24-Ноя-24 (33) +9 [^]
- Вон то на практике вело к дохреналиону багов, увы и ах А абстракции что, как во, Аноним (-), 00:41 , 24-Ноя-24 (44) +2
- int a int b int maxиз этого условия можно вывести weakest predicate и прове, mister_0 (?), 00:47 , 24-Ноя-24 (48) +6 [^]
- Да, но 1 Это лишняя операция 2 Половина долбоклюев это забудет 3 На практик, Аноним (55), 01:11 , 24-Ноя-24 (55) +4
- у тебя есть процессор и три регистра по 32 битаты загрузил в один регистр A 0x10, mister_0 (?), 01:58 , 24-Ноя-24 (62) –1
- Меня для начала колышет в системщине - делать доступы конкретного размера А не , Аноним (-), 07:16 , 24-Ноя-24 (96) +1
- 26 , anon2 (?), 23:05 , 24-Ноя-24 (246)
- [.... слишком большой тред, остальное см. в режиме смотреть все |+ ] (328)!
- Есть регистр флагов, где валидность результата уже видна и не надо городить ваши, Аноним (22), 11:45 , 24-Ноя-24 (145)
- ну проверка битика вообще-то почти халявная Хз почему в низкоуровневом языке ее, нах. (?), 11:49 , 25-Ноя-24 (258)
- Если значение int a отрицательное, будет переполнение при вычитание underflow, Аноним (-), 01:16 , 24-Ноя-24 (56) +6 [^]
- несомненно для отрицательных чисел нужно использовать min int, а ещё конечно не , mister_0 (?), 01:33 , 24-Ноя-24 (59)
- Вместо дорогой пред-проверки с явными сравнениями и несколькими ветками можно бы, Аноним (190), 02:17 , 24-Ноя-24 (64)
- Сначала проверь, что оба положительные, потом вычти одно из max int, сравни со в, Аноним (104), 04:04 , 24-Ноя-24 (73)
- и теперь ты нагородил кучу проверок на пустом месте, которые ещё надо писать , Bottle (?), 09:20 , 24-Ноя-24 (118)
- стандартный вопрос - какому числу равен min int , Аноним (22), 11:52 , 24-Ноя-24 (149)
- А простое сложение расползается кучей кода с кучей багов Спасибо, не надо, Neon (??), 05:38 , 24-Ноя-24 (79)
- если a -10, то приint max - int aбудет оверфлоу, Аноним (91), 06:22 , 24-Ноя-24 (91) –1
- Когда мне нужно было решить задачу проверки на переполнение, я использовал intpr, Аноним (122), 09:33 , 24-Ноя-24 (122) +1
- Зачем тебе тогда си если ты собрался это проверять на каждом сложении Чтобы поб, Аноним (12), 09:55 , 24-Ноя-24 (128)
- Если вам нужен язык для вычислительной математике - берите фортран и не пудрите , Аноним (22), 13:22 , 24-Ноя-24 (170)
- На практике ничего иного не наблюдается Языки с иными свойствами почему-то миру, 21yosenior (?), 08:41 , 24-Ноя-24 (105) +1
- Для вычислений используйте Фортран , Аноним (22), 14:30 , 24-Ноя-24 (176)
- Угу, именно поэтому они это не implementation-defined, не хотя бы unspecified, а, Аноним (-), 00:45 , 24-Ноя-24 (46) +1
- Такова плата за генерацию эффективного кода Никто же не заставляет использовать, анон (?), 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)
- Аноним написал много латинских слов, и думает, что написал что-то умное А на сам, Аноним (104), 09:31 , 24-Ноя-24 (120)
- Ну давай, расскажи мне как ты собрался из Си полагаться на то как происходит сл, Аноним (-), 00:46 , 24-Ноя-24 (47)
- Пусть на ассемблере кодят, раз им нужно сложение на аппаратном уровне в конкретн, Neon (??), 05:35 , 24-Ноя-24 (78) +2
- Вот только всё современное железо реализует это как two s complement, и сложение, morphe (?), 06:13 , 24-Ноя-24 (90) +2
- Просто они знают, что ub является переполнение, а не сложение Поэтому у них всё, 21yosenior (?), 08:39 , 24-Ноя-24 (104)
- Вы видимо не системный программист, раз задаётесь таким простейшим вопросом , Аноним (31), 10:51 , 25-Ноя-24 (254)
- ну так ты проверь перед сложением или можешь после сложения в регистр flags посм, mister_0 (?), 00:37 , 24-Ноя-24 (42) –1
- в С , Аноним (110), 00:48 , 24-Ноя-24 (49)
- ну придётся ассемблерную вставку сделать , mister_0 (?), 00:53 , 24-Ноя-24 (50)
- но я выше ответил, что проще считать post condition выводить weakest predicate и, mister_0 (?), 00:55 , 24-Ноя-24 (51)
- В си __builtin_ _overflow - 1000 лет есть , 21yosenior (?), 08:45 , 24-Ноя-24 (107)
- В сях нет стандартного способа посмотерть флаги, внезапно Wrapround определен и , Аноним (-), 01:04 , 24-Ноя-24 (52)
- Такой системный язык Близкий к аппаратуре, Neon (??), 05:41 , 24-Ноя-24 (82) –1
- Внезапно он еще и про портабельность А имплементация флагов у разных процов - д, Аноним (-), 07:28 , 24-Ноя-24 (97) +1
- Ну, у C есть ещё стандартизированные расширения из ISO IEC TR 18037 Среди кото, Аноним (244), 09:40 , 24-Ноя-24 (124) +1
- Ну вот такой вот хреновый стандарт, со звездочкой и 5-м шрифтом 1 из многочисл, Аноним (195), 16:06 , 24-Ноя-24 (195)
- Ну блин, это была не реклама AVR, а история про то, что если не отмаплено, то в , Аноним (244), 18:33 , 24-Ноя-24 (233)
- А таки вон те кейворды 1 Нестандартны от слова вообще 2 Здорово нагибают пор, Аноним (-), 20:32 , 25-Ноя-24 (303)
- Но всё-таки есть стандарт на добавление подобных кейвордов Наоборот, они избав, Аноним (244), 09:08 , 26-Ноя-24 (317)
> А таки вон те кейворды...
> 1) Нестандартны от слова вообще.Но всё-таки есть стандарт на добавление подобных кейвордов... > 2) Здорово нагибают портирование кода на/с AVR. Наоборот, они избавляют от pgm_read_byte, то есть приближают к современным архитектурам (убрать 1 слово __flash проще, чем убирать все вызовы pgm_read_byte). > При том тупой как дрова. Вот, неплохое свойство для учебного пособия. > Ну я б не назвал его маленьким. Хрен знает, с чем тут можно спорить. Берём STM32 и вроде как официальный современный способ работы с ним. Снизу CMSIS, над ним LL, над ним HAL, а над ним его графическое величество STM32CubeMX. Вот avr-gcc, который фьюзы позволяет прямо в коде прописать, вот прямо над main(), а вот махина, производитель которой настоятельно рекомендует настраивать микроконтроллер с помощью кодогенерации через графическую утилиту. > А контроль нормально делается, пардон, __attribute__((section("whatever")) на объекте Нормально делается там где нормально сделано, а на AVR такой подход, только в виде __attribute__((__progmem__)), возвращает нас к необходимости в pgm_read_byte.
- [.... слишком большой тред, остальное см. в режиме смотреть все |+ ] (329)!!!
- вот кстати, сюда же можно было бы замапить регистры процессора и проверять бит п, фф (?), 13:23 , 25-Ноя-24 (268)
- Не позорься - написал выше этот способ Опять же, нужно меньше позориться un, 21yosenior (?), 08:55 , 24-Ноя-24 (112) +1
- Судя по всему решение хорошее Как иначе объяснить, что весь софт написан на это, 21yosenior (?), 08:38 , 24-Ноя-24 (103)
- Если по факту UB, то и объявить надо, что - UB , Аноним (22), 14:27 , 24-Ноя-24 (175)
- Значит ли это, что gcc 15 будет поддерживать стандарт c23 ПОЛНОСТЬЮ , Аноним (12), 22:46 , 23-Ноя-24 (12) +1
- Всё это ерунда, есть же православный ANSI C C89 Всё остальное 8212 ненужны, Маковод (?), 23:02 , 23-Ноя-24 (15) +9 [^]
- Овер инжиниринг будь проклята автозамена , Маковод (?), 23:03 , 23-Ноя-24 (16) +6 [^]
- Вот ты на нем и прогай А я меньше чем на C99 в принципе не согласен, а лучше ми, Аноним (-), 00:34 , 24-Ноя-24 (41) +2
- Будь мужиком, не останавливайся на C89 Используй триграфы , Аноним (277), 15:06 , 25-Ноя-24 (277) +1
- Расширения GNU давно пора принимать в стандарты С и С Простые и полезные идеи, nc (ok), 23:26 , 23-Ноя-24 (18) –2
- Нет, C практически заморожен И не один GCC имеет власть - не захотят остальные , Аноним (244), 10:29 , 24-Ноя-24 (135)
- Де факто актуальные компилеры C это GCC и Clang Майкрософт хотя-бы C99 уже смог , Аноним (-), 16:23 , 24-Ноя-24 (198) –1
- Так ты 2 2 написал, а сложить не сложил Я сложу из C99 выкинули VLA, C99 стал , Аноним (244), 17:15 , 24-Ноя-24 (220)
- То есть требуется не только чтобы старый код работал в новых компиляторах обрат, Аноним (244), 17:28 , 24-Ноя-24 (223)
- У них, помнится, далеко не только VLA не хватало, по жизни Народ заманался ждат, Аноним (-), 21:22 , 25-Ноя-24 (307)
- Нет, вас MISRA и то, и другое запретила, а вы вольнодумствуете о разумных реакц, Аноним (244), 11:08 , 26-Ноя-24 (318)
> За юзеж такого в МК гнать надо цаными тряпками, имхо, из профессии.Нет, вас. MISRA и то, и другое запретила, а вы вольнодумствуете о разумных реакциях на ошибки malloc (и сопротивляетесь искусительным мыслям об -fstack-protector). > Все нормальные програмеры юзают -Wvla. И на легитимный сценарий из C23 (без аллокаций) он говорит следующую ерунду: "warning: ISO C90 forbids variable length array". Наверное, всё-таки -Wvla ненормальный, а не программисты из комитета. > Dialects это всякие форки и неофициальные отшнуровки. Не нужно додумывать, создатель языка в следующей цитате сообщает, что с помощью [[вот_этого_вот]] можно создать диалект. Если [[вот_это_вот]] изменяло смысл программы, а не помогало искать ошибку или подсказывало оптимизатору - диалект создан. > Но реально - до известного предела.
> Некоторая. И таки - часть вещей deprecated все же сделали
> С C23 будет аналогично
> компильтесь как более старый стандарт!
> То что некто соответствовал C++11 не значит что он автоматом C++2x будет
> Равно как C89 сорец не станет сорцом C23 по взмаху волшебной палочки
> Тем не менее то что старый сорец соберется в режиме нового стандарта никто никому никогда не гарантировал А зачем 7 раз повторять? Затем, что настолько сильны мечты, что C(++) сейчас вот как сбросят груз обратной совместимости, да как покажут. Просто запрягают долго, ага.
- Скрыто модератором, Аноним (244), 12:32 , 26-Ноя-24 (323) [---]
> обратной совместимости
> обратной * и прочая, и прочая совместимости.
- Да кто же эту MISRA будет использовать Если это не критическая программа, то ни, fuggy (ok), 14:03 , 26-Ноя-24 (324)
Да кто же эту MISRA будет использовать. Если это не критическая программа, то никто это использовать не будет. А если критическая, то они использует это и без MISRA и всё равно ошибки допускают. Вот если бы это было встроено в компиляторы на уровне варнингов. А так как нужно для оптимизации иногда ходить по тонкой грани UB они от этого плюются.
- Вообще-то и правильно сделала в своей области, если уж мы об этом И на микрокон, Аноним (-), 17:05 , 26-Ноя-24 (330)
> Нет, вас. MISRA и то, и другое запретила, Вообще-то и правильно сделала в своей области, если уж мы об этом. И на микроконтроллерах я предпочитаю так же как они. Я их читал, и большую часть идей взял в оборот. Это дает мне некое технологическое превосходство над вон теми в виде стабильного, предсказуемого кода. > а вы вольнодумствуете о разумных реакциях на ошибки malloc Если уж полезли рассуждать о сортах г-на, возможность обработки ошибки намного лучше чем просто внезапный прострел черепа, вообще без возможности априорно знать какой N валиден и как либо корректно обработать ошибку. Т.е. VLA это та же динамическая аллокация в рантайме, только минус возможность корректной реакции на ее облом от слова вообще. Самый плохой из сортов динамической аллокации вообще, никогда не знаешь сколько можно - а о том что столько нельзя узнаешь путем прострела черепа. Антифича просто. > (и сопротивляетесь искусительным мыслям об -fstack-protector). Stack protector не позволит перехватить ошибку и сделать что-то осмысленное. Более того - в embedded он вообще зачастую неприменим. Повылезло тут "экспертов" по надежности кода на си. Благодаря таким экспертам у сей репутация багодрома и дыр. > И на легитимный сценарий из C23 (без аллокаций) он говорит следующую ерунду:
> "warning: ISO C90 forbids variable length array". Наверное, всё-таки -Wvla ненормальный,
> а не программисты из комитета. На мой вкус -Wvla должен гасить все array неопределенного размера. Если что-то лишнее гасит, баг в тулчейне, бывает, что делать. > Не нужно додумывать, создатель языка в следующей цитате сообщает, что с помощью
> [[вот_этого_вот]] можно создать диалект. Если [[вот_это_вот]] изменяло смысл программы,
> а не помогало искать ошибку или подсказывало оптимизатору - диалект создан. Ну как бы для МК допустим все и прогали на gnu99 каком - ибо без этого чисто стандартным си сыт не будешь, и лучше б стандартизаторы стандартизировали возможность размещения например объекта в секцию, и тому подобное. > А зачем 7 раз повторять? Затем, что настолько сильны мечты, что C(++)
> сейчас вот как сбросят груз обратной совместимости, да как покажут. Просто
> запрягают долго, ага. В C23 таки и сбросили часть. А кто хотел как C89 компилиться да еще с K&R каким, пусть под ним и компилится, явно запросив именно этот стандарт.
- llvm не лучше обоснуйте, Аноним (-), 00:23 , 24-Ноя-24 (38)
- Вообще-то он указывает что функция никогда не возвращается Скажем main в фирмва, Аноним (-), 00:31 , 24-Ноя-24 (40) +2
- 14 версия при сборке пакетов ругалась на указатели, 15 будет ругаться если код н, Аноним (58), 01:20 , 24-Ноя-24 (58)
- что-то фигня какая-то с auto auto myNum superCalculator 2,2 и иди гадай, ког, мяв (?), 02:59 , 24-Ноя-24 (70) –1
- я ж правильно логику работы auto поняла , мяв (?), 03:00 , 24-Ноя-24 (71) –1
- Какие проблемы Смотрим объявление функции В современных IDE это автоматом под, Neon (??), 05:43 , 24-Ноя-24 (84) –1
- Значит, типизация не строгая Должно сломаться всё по цепочке А то, что ты тип в, Илья (??), 05:48 , 24-Ноя-24 (86) –1
- Да вот блин да, научились у некоторых - а конкретно плюсеров Но порой таки - уд, Аноним (-), 07:45 , 24-Ноя-24 (99)
- причём для передачи структуры по значению ABI требует, чтобы все её поля бережно, arisu (ok), 17:26 , 26-Ноя-24 (331)
> Си вообще забавная штука. Вроде низкоуровневый, но функция на самом деле может
> и получить и вернуть даже struct.причём для передачи структуры по значению ABI требует, чтобы все её поля бережно засунули в стек по одному. нет, не просто блоб-структуру, которую можно потом нормально адресовать, а поля один за одним, как будто это обычные параметры соответствующего типа. мне даже не хочется представлять, чем закидывался тот, кто это придумал.
- Сам по себе стандарт C не регламентирует никакие ABI А для ARM так и вовсе 2 AB, Аноним (-), 00:43 , 27-Ноя-24 (342)
> причём для передачи структуры по значению ABI требует, чтобы все её поля
> бережно засунули в стек по одному.Сам по себе стандарт C не регламентирует никакие ABI. А для ARM так и вовсе 2 ABI этого есть. Ты про которое из ABI и под какую архитектуру? > нет, не просто блоб-структуру, которую можно потом нормально адресовать, Насколько я помню, union на struct вида array[N] - вполне валидная идея вроде. Хотя с этим надо аккуратно, как и с union вообще. В некоторых допущениях такой заподвыподверт даже работает. Но передавать by val имеет смысл только мелкие структуры. Для больших больше жор стека и их копирование туда сюда не особо эффективный код дает. В этом смысле - лучше по указателю, что многие продвинутые сишники нынче для нормальных "structured API" и делают так то с неких пор. > а поля один за одним, как будто это обычные параметры соответствующего типа. И как это выглядит для uint8_t something:2, somethingelse:3 ? > мне даже не хочется представлять, чем закидывался тот, кто это придумал. Там еще бывают заморочки с выравниванием. Но вообще-то сколько я себя помню, абстракция с union на array[] потребного размера, таки, держится. Более того - даже строки всякие можно в struct впихивать (реально, конечно, это указатель). Что прикольно - такой массив struct'ов потом вполне корректно итерируется. Это не я придумал, сперто из мана gcc и доразвито.
- успехов писать на 171 стандарте си 187 как удобно когда надо 8212 down , arisu (ok), 01:21 , 27-Ноя-24 (343)
> Сам по себе стандарт C не регламентирует никакие ABI.успехов писать на «стандарте си». как удобно: когда надо — down to earth, инженер-практик. а когда не надо — будем про сферические стандарты. > Ты про которое из ABI и под какую архитектуру? про x86. >> нет, не просто блоб-структуру, которую можно потом нормально адресовать,
> Насколько я помню, union на struct вида array[N] - вполне валидная идея
> вроде. это всё прекрасно — вот только выравнивание аргументов в стеке во-первых, не обязано совпадать с таковым у структуры, а во-вторых, порядок полей может оказаться перевёрнут из-за calling convention. ура, бедный компилятор вынужден или переписывать весь код внутри функции, которому не повезло со структурой работать, или собирать её обратно во временную переменную, расходуя таким образом стек дважды. отличное решение, чудесные парни придумали. >> а поля один за одним, как будто это обычные параметры соответствующего типа.
> И как это выглядит для uint8_t something:2, somethingelse:3 ? а так и выглядит: как инты. на размерность после двоеточия плевать. впрочем, может именно тут пакуются — этого я точно не помню, конкретно в этом месте могу ошибиться.
- Вообще, вот именно программы под Linux - вполне себе могут быть conforms to И, Аноним (-), 19:26 , 28-Ноя-24 (361)
>> Сам по себе стандарт C не регламентирует никакие ABI.
> успехов писать на «стандарте си».Вообще, вот именно программы под Linux - вполне себе могут быть "conforms to". И, что приятнее, вот этот вот conformant код - можно чаше всего взять и притащить на вон тот мк. И даже работает. Даже если фирмвар и не conforms to целиком. > как удобно: когда надо — down to earth, инженер-практик. а когда не надо —
> будем про сферические стандарты. Да, очень удобно - признать что мир не идеален, и что в правилах иногда допустимы исключения. Зачем бороться с законами природы, если можно - пользоваться ими себе во благо? Я стараюсь быть максимально confrorms to выбранный стандарт - покуда это не начинает откровенно нагибать решение задачи. В этом месте отклонение от идеала допускается, но по возможности - минимизируется. Такая простая и честная полися - следовать goal'ам до тех пор пока это не начинает сильно якорить другие аспекты. Что тут не понятно?
>> Ты про которое из ABI и под какую архитектуру?
> про x86.
Это какой x86? 32? 64? У них IIRC довольно разные ABI. У 32 бит уродца регистров было полторы штуки, ну его поток команд и состоит из пушпопов чуть менее чем полностью. В x86-64 это сделали хоть немного напоминающим нормальный проц. > это всё прекрасно — вот только выравнивание аргументов в стеке во-первых, не
> обязано совпадать с таковым у структуры, а во-вторых, порядок полей может
> оказаться перевёрнут из-за calling convention. В общем случае конкретный layout struct'а в памяти никто и не обещал. Даже с указателями и референсом этого как объекта в памяти соображения по части выравнивания и проч не пустой звук. Но вообще-то struct'ами обычно пользуются вовсе не для того чтобы пытаться рассмотреть их как массив байтов в памяти. А как раз для ровно обратной цели. > собирать её обратно во временную переменную, расходуя таким образом стек дважды.
> отличное решение, чудесные парни придумали. Элементарно лечится использованием указателя на my_struct_t какой. При этом оно все равно типизировано и хрен чего-то другое так по простому туда скормишь с 1 стороны, структурированное апи с другой, а из аргументов - один указатель аж, который вообще обычно не в стеке - а так, регистр какой. Так что минус прологи-эпилоги еще при случае. >> И как это выглядит для uint8_t something:2, somethingelse:3 ?
> а так и выглядит: как инты. на размерность после двоеточия плевать. впрочем,
> может именно тут пакуются — этого я точно не помню, конкретно
> в этом месте могу ошибиться. Ну как минимум в запрашиваемом layout этого подразумевается упаковка. И как минимум на ARM оно делало вполне характерный RMW код, жирноватый и медленноватый, зато - форсящий что вот тут именно 3 бита будет. И можно иной раз не проверять out of range какой, точно зная что более чем 7 такая штука точно не подгонит.
- правда, они даже ввод и вывод делать не могут 8212 потому что в языке си нет , arisu (ok), 20:24 , 28-Ноя-24 (363)
>>> Сам по себе стандарт C не регламентирует никакие ABI.
>> успехов писать на «стандарте си».
> Вообще, вот именно программы под Linux - вполне себе могут быть "conforms
> to".правда, они даже ввод и вывод делать не могут — потому что в языке си нет таких операторов. очень полезно. > И, что приятнее, вот этот вот conformant код - можно
> чаше всего взять и притащить на вон тот мк. И даже
> работает. Даже если фирмвар и не conforms to целиком. так чего бы ему не работать, если там ввода-вывода нет, динамической памяти нет… ничего нет, короче. это всё, на минуточку, библиотеки. >> как удобно: когда надо — down to earth, инженер-практик. а когда не надо —
>> будем про сферические стандарты.
> Да, очень удобно - признать что мир не идеален, и что в
> правилах иногда допустимы исключения. Зачем бороться с законами природы, если можно
> - пользоваться ими себе во благо? а ещё очень удобно делать вид, что не понял, о чём я. так можно отвечать на то, что удобно, а не на то, что обсуждалось. >>> Ты про которое из ABI и под какую архитектуру?
>> про x86.
> Это какой x86? 32? 64? вообще-то 64 называется `x86_64`. или `x64`, если для винды. >> это всё прекрасно — вот только выравнивание аргументов в стеке во-первых, не
>> обязано совпадать с таковым у структуры, а во-вторых, порядок полей может
>> оказаться перевёрнут из-за calling convention.
> В общем случае конкретный layout struct'а в памяти никто и не обещал. и то, что одна структура может иметь несколько видов в пределах одной программы — тоже. > Но вообще-то struct'ами обычно пользуются вовсе не для того чтобы пытаться рассмотреть
> их как массив байтов в памяти. А как раз для ровно
> обратной цели. спасибо, что просветил меня о том, зачем нужны структуры. я-то всё гадал: добавили бесполезную штуку, а нафига? теперь поясни, пожалуйста, какое это имеет отношение к обсуждаемой теме — ABI для передачи структур по значению. >> собирать её обратно во временную переменную, расходуя таким образом стек дважды.
>> отличное решение, чудесные парни придумали.
> Элементарно лечится использованием указателя на my_struct_t какой. а ничего, что это меняет семантику программы, потому что получается передача по ссылке? хотя какая ерунда, кого та семантика волнует… > Ну как минимум в запрашиваемом layout этого подразумевается упаковка. ты специально делаешь вид, что не можешь запомнить тему обсуждения, и типа-отвечаешь на совсем не относящееся к?
- А stdio h это что, мой глюк Тот же printf можно и на мк завести Он в полной р, Аноним (-), 06:06 , 30-Ноя-24 (372)
> правда, они даже ввод и вывод делать не могут — потому что
> в языке си нет таких операторов. очень полезно.А <stdio.h> это что, мой глюк? > так чего бы ему не работать, если там ввода-вывода нет, Тот же printf можно и на мк завести. Он в полной реализации жирноват, и только. И так, рассматривая интерактивную текстовую дебагменюху в терминалке сбоку IDE и 3Mbps поток trace активности FW который оно льет в usb-to-serial uart, этакий реалтайм трейс, с визуализацией ключевых событий/параметров - чего у меня нету? Я даже i2c/spi чипы памяти read/write научился. Как я все это без IO? :). Идея конечно не моя, сперто у фирмачей. Просто я ничем не хуже них и тоже могу так же. Даже с DMA queue UARTа, чтоб тайминги фирмвари не рушить особо, DMA в UART это все в фоне сам скидывает. А чисто для себя я забахал интерактив с степпером. Всегда хотел поприкалываться, забавно когда жмешь кнопки как в кваке - степпер туда сюда гоняет, можно параметры типа таймингов интерактивно крутить, сколько шагов и проч :). Вот это я понимаю, ввод-вывод здорового человека. Десять влево, пять вправо... а - слабо - бибикнуть моторчиком?! Когда реалтайм at fingertips, то и моторчик - динамик, типа. У меня есть и ряд более интересных вещей по части IO - куда менее унылых чем твое видение этого. Начиная от нестандартного использования LED на манер статьи которую постили, внезапно, тут, до кастомных "емкостных" вещиц и самопальных RF линков, где я делаю с битами и математикой вещи далеко за пределами твоих самых смелых фантазий. > динамической памяти нет… ничего нет, короче. это всё, на минуточку, библиотеки. Ну я и не обещал что ты POSIX приложуух на мк без изменений запустишь. Хотя отдельные извращенцы пытаются. Смысл этого хз - но так можно. И да, тот же UART - вполне себе stdin/stdout по смыслу. А де факто - простой коммуникационный канал с хостом, фича оного - на минималках он столь прост что это первое что обычно прогают при bring up чтобы увидеть что железка - реально завелась. Можно также трейсить на чем именно затык в читабельном виде. > а ещё очень удобно делать вид, что не понял, о чём я. так можно отвечать на то,
> что удобно, а не на то, что обсуждалось. Тебе не приходило в голову что мы думаем довольно по разному? >> Это какой x86? 32? 64?
> вообще-то 64 называется `x86_64`. или `x64`, если для винды. Для меня x86-32 по сути не существует уже. Это махровое легаси, о котором лично я скучать не буду. Все мои x86 системы 64-битные, даже 32 бит либ не установлено, 64 бита end to end. Так что какое там ABI у этого антика было - для меня бесполезное знание, уж сорь. Если мы про x86-64 это еще может быть для меня интересно, а из 32 битных меня интересует разве что мелочь на ARM и RISCV. Программировать компы более чем 20 летней давности я не собираюсь. И на лично мое мнение x86-32 был отвратительным процом. > и то, что одна структура может иметь несколько видов в пределах одной
> программы — тоже. Я вообще не понимаю нужду шарахаться по struct "raw" доступом. То-есть на си чисто технически можно сделать немало странных вещей, но это имхо из разряда "доктор, когда я так делаю, мне больно - а вы так не делайте!" На ARM это настолько хорошо работает что mem-mapped железки задефайнены (typedef) как struct'ы, вплоть до битовых полей. И это официальный код от ARM, STM32 и проч, если им нормуль, то и мне тоже. Доступ от фонаря в те штуки вообще - нельзя, ибо половина железок умеет например только "could be accessed by 32-bit words". Если попробовать 8 или 16 бит доступ, это вообще unspecified, а еще биты регистра могут меняться сами (железом) так что идея RMW на этом софтом - чревата тем, что пока некто оперировал с битовым полем, железка поменяет битик, и запись улетит с некорректным значением. И удачи в дебаге - такое может быть раз в пару лет, счастливой отладки. > добавили бесполезную штуку, а нафига? теперь поясни, пожалуйста, какое это имеет
> отношение к обсуждаемой теме — ABI для передачи структур по значению. Ну я уже уточнил наиболее интересное - про какой именно ABI речь. C как стандарт вообще ABI не указывает. А про x86-32 лично я уже - забыл. Меня не интересует эта платформа. Так что если это про x86-32 было, я завершаю эту дискуссию. >> Элементарно лечится использованием указателя на my_struct_t какой.
> а ничего, что это меняет семантику программы, потому что получается передача по
> ссылке? хотя какая ерунда, кого та семантика волнует… Меняет. Но так как правило даже удобнее получается на самом деле. >> Ну как минимум в запрашиваемом layout этого подразумевается упаковка.
> ты специально делаешь вид, что не можешь запомнить тему обсуждения, и типа-отвечаешь
> на совсем не относящееся к? Разговор про ABI - вообще имеет смысл только с уточнением про какое ABI речь. Ибо их было более 1 и есть разные архитектуры. В ABI x86-32 я вообще не силен - ибо для меня это настолько легаси что я просто не собираюсь раскапывать эти кости уже. И за нормальный проц это я ессно не считаю. Дедушка славно поработал, ему пора на пенсию. А вот си переживет и тебя, и меня.
- ух ты, это у нас теперь часть языка эвона как как это ты же выше сам сказал, ч, arisu (ok), 06:25 , 30-Ноя-24 (374)
>> правда, они даже ввод и вывод делать не могут — потому что
>> в языке си нет таких операторов. очень полезно.
> А <stdio.h> это что, мой глюк?ух ты, это у нас теперь часть языка. эвона как. >> динамической памяти нет… ничего нет, короче. это всё, на минуточку, библиотеки.
> Ну я и не обещал что ты POSIX приложуух на мк без
> изменений запустишь. как это? ты же выше сам сказал, что это часть языка. > Для меня x86-32 по сути не существует уже. Это махровое легаси, о
> котором лично я скучать не буду. Все мои x86 системы 64-битные,
> даже 32 бит либ не установлено, 64 бита end to end. бывает, чо. «все побежали — и я побежал.» дополнительный штрих к твоему неумению оценивать технологии самостоятельно, а не по чужим мнениям. >> и то, что одна структура может иметь несколько видов в пределах одной
>> программы — тоже.
> Я вообще не понимаю нужду шарахаться по struct "raw" доступом. потому что ты в жизни ни одного серьёзного компилятора не написал. поэтому ты так и не понял, о чём я речь вёл. хрен его знает, зачем ты попытался зарубиться со мной на теме компиляторов, ничего в этом не понимая. >> а ничего, что это меняет семантику программы, потому что получается передача по
>> ссылке? хотя какая ерунда, кого та семантика волнует…
> Меняет. Но так как правило даже удобнее получается на самом деле. я ни разу не удивлён, что ты считаешь девелоперов гоцэцэ нормальными. > А вот си переживет и тебя, и меня. и что? кобол ещё жив, фортран ещё жив. мало ли ерунды никак помереть не может. уродец x86 вон, например (и нет, x86_64 лучше не сделал).
- Зато, как славно показали себя иные адепты строгой и явной типизации и отсутстви, Бывалый Смузихлёб (ok), 08:57 , 24-Ноя-24 (113)
- В С auto есть уже достаточно давно, и да, может вызывать проблемы В том числе, ProfessorNavigator (ok), 12:51 , 24-Ноя-24 (162) +1
- Не позволяйте автомату компилятору определять ваш код за вас Кроме того есть , Аноним (22), 18:45 , 24-Ноя-24 (235) –1
- Это называется автовывод Советую посмотреть на ML , Вы забыли заполнить поле Name (?), 19:47 , 24-Ноя-24 (242) +1
- Увы, если для С это имеет смысл, чтобы не писать типы из 100500 шаблонов прив, nobody12 (?), 10:31 , 25-Ноя-24 (253)
- А в сях 100500 макросов Ядро линукса, поиск гитхаба, ищем где используют кривые , Аноним (244), 14:19 , 25-Ноя-24 (269) +1
- typeof var это мягко говоря не синоним auto и может использоваться чертовой куч, Аноним (-), 21:25 , 25-Ноя-24 (309)
- А буквой t ещё древние римляне пользовались Я ведь полную конструкцию привёл, н, Аноним (244), 08:15 , 26-Ноя-24 (316)
>> typeof(var) ... = ... var - до 1000 файлов
> typeof(var) это мягко говоря не синоним auto и может использоваться чертовой кучей
> иных способов.А буквой t ещё древние римляне пользовались. Я ведь полную конструкцию привёл, не надо её обрезать. > Да, начните. Сделайте свой проект, дайте этому негодяю мастеркласс. - ананасы в пицце (вывод типов в C) - это вредительство
- пиццерия на букву G давным-давно добавила, а в неё ходит коллектив L
- займитесь ими!
- ??? Это вы здесь вредительство искали. Или уже вредительство уже не вредительство, когда оказалось, что его Линус одобрил?
- Зачем снова новый тип char8_t, если уже есть char и unsigned char Более того ес, Аноним (77), 05:35 , 24-Ноя-24 (77) –1
- Почему Ы Чтоб никто не догадался , Neon (??), 05:44 , 24-Ноя-24 (85)
- Почему А потому что диды-недостандартописаки смогли подоcpaть даже в такой прос, Аноним (-), 11:24 , 24-Ноя-24 (140)
- Потому что стандартом символа стал уникод Кроме того это унификация под типы фи, Аноним (22), 12:27 , 24-Ноя-24 (154)
- Давайте проведем эксперимент в Debianvi test c include stdio h int main int arg, Truth Seeker (?), 14:54 , 24-Ноя-24 (182) –1
- Ну, для начала - не проверяешь что argv 1 вообще был, хотя-бы Так что если , Аноним (-), 16:28 , 24-Ноя-24 (199)
- Не проверяю для краткости Вопрос не об этом Привет - это UTF-8 строка, а в , Truth Seeker (?), 16:48 , 24-Ноя-24 (208)
- Так Вы со строкой ничего и не делаете, а выводите что дали Длина и то, по завер, _kp (ok), 16:14 , 25-Ноя-24 (284)
- А вы вообще знаете как правильно считать посимвольно какие-нибудь иероглифы, вся, Аноним (-), 06:17 , 30-Ноя-24 (373)
> Так Вы со строкой ничего и не делаете, а выводите что дали.
> Длина и то, по завершающему нулю.
> А вот если, например, посимвольно будете выводить, или посчитать длину..А вы вообще знаете как правильно считать посимвольно какие-нибудь иероглифы, всякие там модификаторы, RTL/LTR и тому подобные приколы? Unicode в этом смысле - тот еще брейнфак получился. А вот смайликов не хотели? А еще и цветных, а?!
- test Привет hello txthexdump -C hello txt00000000 d0 9f d1 80 d0 b8 d0 b2 , Truth Seeker (?), 17:00 , 24-Ноя-24 (216)
- Думаю, Вы привели неудачный аргумент Всегда нужно знать, какие аргументы переда, Аноним (46), 14:36 , 25-Ноя-24 (271)
- Вот сразу видно счастливого человека Ни разу не е ался с длинами символов и коди, Аноним (259), 11:51 , 25-Ноя-24 (259) +1
- Так это уже не тот язык С, который придумали его изобретатели Брайан Керниган и , Аноним (87), 05:50 , 24-Ноя-24 (87) –3
- Так это тоже уже не тот язык С - в K R C не было UB поэтому переиздание книжк, Аноним (244), 10:42 , 24-Ноя-24 (136)
- Опции GCC, управляющие диалектом языка https gcc gnu org onlinedocs gcc C-Dial, Аноним (22), 18:52 , 24-Ноя-24 (238)
- Я тебе скажу, о ужас , суровую правду жизни ты и на русском языке говоришь не , Bottle (?), 17:31 , 25-Ноя-24 (294)
- Оригинальный язык С описан в книге The C Programming Language Кернигана и Ритч, Аноним (87), 05:53 , 24-Ноя-24 (88) –1
- Также языком С лично я считаю язык представленный в книге The C Programming , Аноним (87), 06:01 , 24-Ноя-24 (89) +1
- Это меня огорчает, у меня есть ещё код в подобном стиле , ijuij (?), 06:35 , 24-Ноя-24 (92)
- А так мне все нововведения нравятся, и особенно хочу отметить это 128285 , ijuij (?), 06:46 , 24-Ноя-24 (93)
- Мммм Как же мне не хватало переменных длиной 3, 7, 11 бит, Аноним (101), 07:47 , 24-Ноя-24 (101)
- Это ж какой простор для UB Ну и вообще, полностью идёт вразрез с идеей сишки Вс, Аноним (109), 08:53 , 24-Ноя-24 (109) +1
- Там внедрено много кода, взгляни на коммиты в GCC https github com search q re, ijuij (?), 09:00 , 24-Ноя-24 (114)
- т е когда поле структуры 3,7,11 бит - это не идет в разрез,а вот когда это отде, Советский инженер (ok), 11:29 , 24-Ноя-24 (142)
- Есть масочная операция над регистром и есть ячейка памяти , Аноним (22), 12:41 , 24-Ноя-24 (158) –1
- Но это не ответ на вопрос о bitfield ах , Аноним (244), 12:48 , 24-Ноя-24 (160) +1
- А в чем проблема чтобы расширить битовые поля чтобы они не были только в struct , Аноним (-), 16:34 , 24-Ноя-24 (204) +2
- struct это сущностьБитовое поле это дополнительная операция над сущностью Биты н, Аноним (22), 18:21 , 24-Ноя-24 (230)
- Так можно сказать что и байты не хранятся, потому что компиляторы выравнивают ра, Аноним (-), 19:45 , 24-Ноя-24 (241)
- Смотря на каких аппаратных архитектурах Где то и косвенно адресуемые биты есть , _kp (ok), 16:25 , 25-Ноя-24 (287)
- И тут стоит сказать что таки да - вон то вызывает чаще всего не особо эффективны, Аноним (-), 21:32 , 25-Ноя-24 (311)
> struct это сущность
> Битовое поле это дополнительная операция над сущностью.
> Биты не хранятся.И тут стоит сказать что таки да - вон то вызывает чаще всего не особо эффективный RMW на этом всем. Так что код воображения не поражает. Зато если у меня скажем есть enum с 4 состоянияи и я поле в struct сделал :2 и все 4 корректно рюхаются internals - потуги скормить что-то откровенно левое в функцию желавшую в "поле апи" нечто в интервале 0..3 станет - мягко говоря - довольно нетривиальным занянием. Это при случае - свалит компил, ибо запросто будет как минимум жырный варнинг про невозможность represent вон то в вот этом. Чем спасет от какого-нибудь жирного бага в рантайме, в фирмвари, где-то уже сильно опосля.
- Это изначально было неудобно и было вкусовщиной , Аноним (22), 12:44 , 24-Ноя-24 (159)
- Успехов GCC конечно, но лучше я буду использовать odin-lang и даже zig-lang уже , Аноним (100), 12:26 , 24-Ноя-24 (153) +1
- которое теперь приводит к выводу типа при определении объектов, что позволяе, Аноним (156), 12:30 , 24-Ноя-24 (156)
- На С 23 я уже видел проекты, а кто-нибудь видел проект на С23 , Аноним (-), 13:04 , 24-Ноя-24 (164)
- Это ещё одно доказательство того, что GCC самый передовой в Мире компилятор , Аноним (-), 16:46 , 24-Ноя-24 (207)
- Раньше чтобы десятичное число вывести в двоичном виде как делали , Аноним (-), 17:44 , 24-Ноя-24 (226)
- А есть где нибудь статистика используемых ассемблерных инструкций тем или иным к, Аноним (22), 18:30 , 24-Ноя-24 (232)
- Что это было , Аноним (247), 20:53 , 24-Ноя-24 (243) –1
- Вона ещё было Тоже с каких-то древних годов тащили , fuggy (ok), 01:52 , 25-Ноя-24 (247)
- в плюсах можно писать main и в си только main void -- насколько это хорошая и, Аноним (6), 11:42 , 25-Ноя-24 (256)
- Подобные вещи к плюсам вообще отношения не имеют, как раз их назад тащить есть с, Аноним (237), 12:12 , 25-Ноя-24 (260)
- Почему нет Пишу алгоритмы бэкэнды фактически на C с использованием удобных, к, Аноним (46), 14:29 , 25-Ноя-24 (270) –1
- Это глупость Либо пишешь на си, чтобы не иметь недостатков плюсов, либо на плюс, Аноним (6), 15:01 , 25-Ноя-24 (276) +1
- И что вам это ABI так жить мешает Ну перекомпилируете ваш код, если что Есть ж, Аноним (87), 17:20 , 25-Ноя-24 (292)
- В реальном коде будут бинарные компоненты, да и в целом пересобирать все зависим, Аноним (6), 17:37 , 25-Ноя-24 (295)
- угу всё бросил и побежал перекомпилировать, как только бравые парни в g что-т, arisu (ok), 17:37 , 26-Ноя-24 (334)
> И что вам это ABI так жить мешает? Ну перекомпилируете ваш код,
> если что.угу. всё бросил и побежал перекомпилировать, как только бравые парни в g++ что-то сломали. ну, я ж программы и библиотеки пишу не для того, чтобы решать практические задачи, а чтобы писать программы и библиотеки. по какой-то странной причине (недосмотр, надеюсь, его скоро исправят) код на си перекомпилировать не надо. с нетерпением жду отмены этой устаревшей концепции.
- Это плохая практика Большинство людей от этого давно отошли Пиши либо на чисто, Аноним (-), 16:17 , 25-Ноя-24 (285) +1
- Всё же ты пишешь на с , возможно, иногда делая вставки на си , Аноним (100), 01:42 , 26-Ноя-24 (312)
Всё же ты пишешь на с++, возможно, иногда делая вставки на си.
- можно и классику - int main -1 , _kp (ok), 17:11 , 25-Ноя-24 (291)
- Лучше бы использовали С89 по умолчанию , Аноним (272), 14:38 , 25-Ноя-24 (272)
- Скрыто модератором, Аноним (-), 15:17 , 25-Ноя-24 (279) [---]
- Код, соответстующий C89, гораздо красивее, совместимость выше, его все использую, Аноним (302), 19:25 , 25-Ноя-24 (302) +1
- Согласен на 98 , InuYasha (??), 20:57 , 27-Ноя-24 (350)
- Представим, что каждые 5 лет обновляется учебник родного языка Причем заменяетс, Аноним (46), 14:47 , 25-Ноя-24 (274)
- Да компиляторы все равно обратную совместимость сохранят, не беспокойся , Аноним (272), 15:13 , 25-Ноя-24 (278)
- ага как gcc13, например, который стал ругаться на snprintf buf, sizeof buf , , arisu (ok), 17:41 , 26-Ноя-24 (335)
> Да компиляторы все равно обратную совместимость сохранят, не беспокойся.ага. как gcc13, например, который стал ругаться на `snprintf(buf, sizeof(buf), "…", …)`. вот не нравится ему, что я возвращаемое значение не проверяю. и он яростно ругается на то, что вывод-де усечён может быть. подумаешь, это же всего лишь легитимное применение стандартной функции, мне так и надо. а нет, компилятору видней. `(void)snprintf(…)` его не убеждает заткнуться. ура, бесполезный ворнинг на пустом месте! именно то, о чём я мечтал: ещё одна дурацкая диагностика, которую надо отфильтровывать. что ещё там отфильтруется вместе с ней в будущем — неизвестно. а мне потом присылают репорты: «у тебя ворнинг там, это же вулнерабилити!» и вроде бы человек хорошего желает, но отчего его так хочется матом послать?
- Ну ты то известный раздолбай-концептуал, уж прости Это таки случай когда семеро, Аноним (-), 17:58 , 26-Ноя-24 (337)
> ага. как gcc13, например, который стал ругаться на `snprintf(buf, sizeof(buf), "…",
> …)`. вот не нравится ему, что я возвращаемое значение не проверяю. Ну ты то известный раздолбай-концептуал, уж прости. Это таки случай когда семеро 1 не ждут, и в целом - это улучшает состояние дел. А ты если такой гениальный и тебе лучше всех виднее как надо - вот и отношайся с отключением варнинга. Или програмь на обероне. Или как там тебе удобно. > и он яростно ругается на то, что вывод-де усечён может быть.
> подумаешь, это же всего лишь легитимное применение стандартной функции, мне так
> и надо. а нет, компилятору видней. Именно так. All в целом весьма утомили постоянные факапы, грабли с топором на ручке - и все же решено было топор с рукояти грабель - по возможности снимать. Даже если кому-то суперкомбо инструмент и удобен был, пусть лучше это будет проблемой десятка желателей странного чем половины глобуса. Такой инженерно-человеческий tradeoff. > мечтал: ещё одна дурацкая диагностика, которую надо отфильтровывать. что ещё там
> отфильтруется вместе с ней в будущем — неизвестно. а мне потом
> присылают репорты: «у тебя ворнинг там, это же вулнерабилити!» и вроде
> бы человек хорошего желает, но отчего его так хочется матом послать? Потому что ты что-то делаешь явно не так. И это в целом - подход к программизму, угу. Игнорить значения функций которые не void - моветон.
- угу и игнорирование явного указания на то, что я понимаю, что делаю 8212 в в, arisu (ok), 18:11 , 26-Ноя-24 (338)
> Ну ты то известный раздолбай-концептуал, уж прости. Это таки случай когда семеро
> 1 не ждут, и в целом - это улучшает состояние дел. угу. и игнорирование явного указания на то, что я понимаю, что делаю — в виде `(void)snprintf()` — тоже улучшает. слава роботам! > А ты если такой гениальный и тебе лучше всех виднее как
> надо - вот и отношайся с отключением варнинга. нет, мне не надо. я вообще перестал обновлять gcc после шестой версии. надо было ещё раньше, конечно. а вот пипол настаивает на сборке новыми гоцэцэ, потому что других в их дистрибутивы не завезли. и потом капает мне в мозг идиотией, место которой — в багтрекере гоцэцэ. в итоге идиоты — там, а зря тратят время — пользователи и я. > Или програмь на обероне. вообще-то в основном так и делаю. ещё и с самописным компилятором. но иногда, по просьбам, так сказать, общественности… и тут оно Как Прыгнет! > Именно так. All в целом весьма утомили постоянные факапы, грабли с топором
> на ручке - и все же решено было топор с рукояти
> грабель - по возможности снимать. при этом контроль выхода за границы массива — что и является источником подавляющего большинства багов — нет, не будем. а вот по поводу совершенно безопасной `snprintf()`, которая хучь лопни, но больше буфера не запишет — вот тут мы будем кричать. это называется не секурити, это называется snake oil. > Даже если кому-то суперкомбо инструмент и
> удобен был, пусть лучше это будет проблемой десятка желателей странного чем
> половины глобуса. Такой инженерно-человеческий tradeoff. поясни мне, пожалуйста, почему усечение вывода в `snprintf()` — это опасно, а выход за границы массива — безопасно? а то я старый, никак не пойму. > Потому что ты что-то делаешь явно не так. ага. ищу ключи не под фонарём, а там, где потерял. это сейчас немодно. > Игнорить значения функций которые не void - моветон. и что мне с этим значением делать? поясни, будь добр. я-то использую `snprintf()` именно затем, чтобы он мне больше буфера не записал. никакого другого метода для этого в стандартной библиотеке нет. вот получил я количество записаных символов — и? оно мне совершенно неинтересно. предлагаешь проверять, не больше ли оно буфера, вдруг у меня libc поломаный? ну, тогда у меня явно намного более серьёзные проблемы, чем эта мелочь. а в любых других случаях мне без разницы. итак: где тут страшная ошибка, где тут угроза секурити? уж раз начал — то будь любезен, поясни до конца. я с удовольствием поучусь.
- Это как бы уже некий тупняк, но да - роботам слава Я в паре мест плевался на ст, Аноним (-), 03:09 , 27-Ноя-24 (344)
> угу. и игнорирование явного указания на то, что я понимаю, что делаю
> — в виде `(void)snprintf()` — тоже улучшает. слава роботам!Это как бы уже некий тупняк, но да - роботам слава. Я в паре мест плевался на статические анализаторы еще не так. Но они нашли мне немало интересных проблемных мест взамен. На мой вкус, круто когда программа сразу работает - и не страдает багами и вулнами. И для меня это довольно многое прощает. Чисто технически потука игнорить коды возвраты того что возвращало какие-то значения - в моих глазах "техническая ошибка". > нет, мне не надо. я вообще перестал обновлять gcc после шестой версии. А я от сабжа не откажусь. В нем есть ряд полезных мне вещей. Перейдя с 8 на 12 у меня размер энной фирмвари Cortex-M на кило сдулся, а перфоманс прибавился. И минус дофига багов LTO, так что его стало реально юзать! Еще минус четверть кода! Меня это колыхало, потому что оно на грани емкости флешки было, а тут EPIC WIN на ровном месте, и полно места, и быстрее, вау! Какой код генерил GCC6 - я даже не помню. Но вероятно еще хуже. И вот что что а улучшение анализа GCC с моей стороны весьма велкам. В новых версиях еще и статический анализатор есть. > надо было ещё раньше, конечно. а вот пипол настаивает на сборке
> новыми гоцэцэ, потому что других в их дистрибутивы не завезли. Хорошо что это не мои проблемы, ибо я разборчив в софте и апстримах. >> Или програмь на обероне.
> вообще-то в основном так и делаю. ещё и с самописным компилятором. но
> иногда, по просьбам, так сказать, общественности… и тут оно Как Прыгнет! Это ваш жабогадюкинг. А с моей стороны улучшение статического анализа и варнингов были причиной обновить GCC. И да, я могу и подконопатить варнинг местами. Это конечно анноянс, но - куда лучше чем вулнов и багов пачка. > при этом контроль выхода за границы массива — что и является источником
> подавляющего большинства багов — нет, не будем. Вообще сто лет как можно, -fsanitize=undefined на минималках даже на МК ок - там он не будет линковать огромную либу, просто bad opcode воткнет для исключения (AVR в этом смысле в пролете как я понимаю). А с -fsanitize=address,undefined оно довольно устойчивое к факапам работы с памятью. Но жабу и дотнет напоминать начинает. > — вот тут мы будем кричать. это называется не секурити, это
> называется snake oil. Это называется - артефакт от комплексных антибажных мероприятий. Бывает. > поясни мне, пожалуйста, почему усечение вывода в `snprintf()` — это опасно, Игнор возврата функций которые что-то возвращали - отличный индикатор факапов и багов. > а выход за границы массива — безопасно? а то я старый, никак не пойму. Эта штука очень уж не халявная в рантайме по скорости и размеру кода. Даже минимальный ubsan - в фирмвари МК раздул ее на четверть, и убил скорость на треть. С этим можно жить на минималках, но... такое себе. А, да, я вообще ниипу, работало ли ЭТО в GCC6. > ага. ищу ключи не под фонарём, а там, где потерял. это сейчас немодно. Не, считаешь себя самой умной клавой на планете на манер кента. > и что мне с этим значением делать? поясни, будь добр. я-то использую
> `snprintf()` именно затем, чтобы он мне больше буфера не записал. Вообще, часто тот факт что truncate случился еще и внимния требует. Ибо есть шанс что получили не то что задумано. > никакого другого метода для этого в стандартной библиотеке нет. вот получил я
> количество записаных символов — и? оно мне совершенно неинтересно. предлагаешь проверять,
> не больше ли оно буфера, вдруг у меня libc поломаный? Не, но зачастую факт truncate интересен - из соображений что в буфере не то что ожидалось. И игнор результата вызова сам по себе - баг. Вот почему void так себя ведет хз, в принципе это можно и багом назвать. Ну, заткнуть #pragma какой-нить. Я тебя в всем этом нытье не пойму: я с учетом общего состояния дел за то чтобы antibug закрутить по максимуму. А ты можешь юзать свой GCC6 до опупения, соответственно. А я буду юзать - более секурный, стабильный и предсказуемый код. И вроде в такой схему все довольны. Не? > страшная ошибка, где тут угроза секурити? уж раз начал — то
> будь любезен, поясни до конца. я с удовольствием поучусь. Угроза секурити? В буфере может быть не то что ожидал прогер -> прога может сделать не то что задумано. Это может быть и угрозой безопасности. Из определения вулнов от DJB.
- 8230 который авторы гоцэцэ багом не считают к сожалению, соответствующий тике, arisu (ok), 08:38 , 27-Ноя-24 (345)
>> угу. и игнорирование явного указания на то, что я понимаю, что делаю
>> — в виде `(void)snprintf()` — тоже улучшает. слава роботам!
> Это как бы уже некий тупняк…который авторы гоцэцэ багом не считают. к сожалению, соответствующий тикет в их багтрекере уже не найду: с какого-то момента я перестал сохранять примеры их идиотии. > но да - роботам слава. Я
> в паре мест плевался на статические анализаторы еще не так. Но
> они нашли мне немало интересных проблемных мест взамен. скажи, а почему так получается: когда я про конкретную проблему веду речь — ты сразу перескакиваешь на общие рассуждения. а когда я про общие рассуждения — ты мгновенно отвечаешь, что тебе это неинтересно, что ты практик? я тебе показал конкретную проблему. какое к ней отношение имеют рассуждения об анализаторах, о том, что «надо проверять значения, возвращаемые функциями», вот это всё? > На мой вкус, круто когда программа сразу работает - и не страдает
> багами и вулнами. у меня так происходит уже много лет. с тех пор, как я действительно грок, о чём писал Дейкстра. санс опечатки, и нечастые ошибки в доказательствах (errare humanum est). опечатки компилятор иногда ловит, ошибки в доказательствах почему-то нет, даже с -Wall -Wextra -Wrealyreallyeverythingplease. > технически потука игнорить коды возвраты того что возвращало какие-то значения -
> в моих глазах "техническая ошибка". писать на языке валидные конструкции, которые языком разрешены — это не ошибка. или вся сишечка ошибка. одно из двух. >> нет, мне не надо. я вообще перестал обновлять gcc после шестой версии.
> А я от сабжа не откажусь. я очень за тебя рад. какое это отношение имеет к тому, с чего я начал речь? где я тебя уговаривал от чего-то отказываться? проблему «у меня не помещается на флэшину» я буду решать тогда, когда она у меня будет. пока что речь о том, что GCC13 начал ругаться не просто на валидный код, но на использование поведения функции, которое описано в её документации. и мне не нравится, что авторы гоцэцэ счтают себя более осведомлёнными в том, что я хотел написать в моей программе. при этом на `+` они отчего-то не ругаются — а это опасная операция, которая может привести к UB со знаковыми целыми! главный поинт моих возмущений в том, что с каждым новым релизом гоцэцэ сыпет всё больше бесполезных мусорных ворнингов, при этом продолжая игнорировать реальные ошибки, из-за которых происходит основная масса проблем. это называется ИБД. причём вредное, так как приучает к мысли, что проще всего ворнинги вообще отключить, потому что кто его знает, какие потрясающие своей гениальностью идеи принесёт ветром в пустые черепа разработчиков гоцэцэ в следующий раз, и что они решат сломать. кстати, пользуясь случаем передаю привет и авторам binutils, которые в одном из *официально* *выпущеных* релизов умудрились сломать конструкторы статических объектов в крестах (и, кажется, атрибут constructor в gnuc тоже). это не «мелкий баг», как ты понимаешь. если *такое* в оффрелизы просачивается… в общем, binutils я тоже уже много лет не обновляю. во избежание. >> надо было ещё раньше, конечно. а вот пипол настаивает на сборке
>> новыми гоцэцэ, потому что других в их дистрибутивы не завезли.
> Хорошо что это не мои проблемы, ибо я разборчив в софте и
> апстримах. и не мои, конечно, потому что я сообщаю, что гоцэцэ выше шестого официально не поддерживается. однако ж жалко человеков. как я уже писал — идиоты в гоцэцэ, а страдают пользователи. > Это ваш жабогадюкинг. ага. и ещё кучи народа. пипол периодически пытается найти у авторов гоцэцэ зайчатку разума через багтрекер, но безуспешно. сломаный по умолчанию на x86 ABI, например, девелоперы гоцэцэ тоже не считают багом. > А с моей стороны улучшение статического анализа и варнингов
> были причиной обновить GCC. поскольку я пишу на сишечке или примерно как на обероне, или код, который ни один анализатор не понимает (потому что именно в этом месте мне нужен именно такой изврат, но нет желания писать его на асме) — то полезного там для меня ничего. есть у меня друзья, которые шутки ради любят гонять мой софт через несколько анализаторов. за годы и годы это нашло несколько мелких ошибок, и огромные портянки false positives. >> при этом контроль выхода за границы массива — что и является источником
>> подавляющего большинства багов — нет, не будем.
> Вообще сто лет как можно, -fsanitize=undefined на минималках даже на МК ок
> - там он не будет линковать огромную либу, просто bad opcode
> воткнет для исключения (AVR в этом смысле в пролете как я
> понимаю). А с -fsanitize=address,undefined оно довольно устойчивое к факапам работы с
> памятью. Но жабу и дотнет напоминать начинает. обсечение в `snprintf()`, несомненно, намного опасней и источник намного большего количества багов ирл. поэтому валидный код с `snprintf()` мы будем ругать, массивы мелочь, не стоят внимания. включите вон тот флаг, ага. с которым куча вещей не работает, а чтобы это работало в принципе хоть как-то надёжно — пересоберите с этим флагом весь мир. и плевать, что он у вас даже не соберётся. >> — вот тут мы будем кричать. это называется не секурити, это
>> называется snake oil.
> Это называется - артефакт от комплексных антибажных мероприятий. Бывает. когда факапы случаются регулярно, и авторы не желают признавать, что это факапы, считая себя самыми умными на планете… что ты про кента писал, а? ;-) >> поясни мне, пожалуйста, почему усечение вывода в `snprintf()` — это опасно,
> Игнор возврата функций которые что-то возвращали - отличный индикатор факапов и багов. почему тогда гоцэцэ не ругается при тех же настройках на *все* случаи такого игнора? знаешь, или трусы, или крестик. оберон, например, просто не скомпилирует программу, в которой функция вызывается как процедура. >> а выход за границы массива — безопасно? а то я старый, никак не пойму.
> Эта штука очень уж не халявная в рантайме по скорости и размеру
> кода. на x86 — в районе zero cost. одно cmp, один бранч, который в подавляющем большинстве случаев not taken. стоит какие-то секунды на числодробилках с массивами, которые работают часами. meh. не, ну ты ж начал про армы — значит, и я могу аргументировать x86-архитектурой. >> ага. ищу ключи не под фонарём, а там, где потерял. это сейчас немодно.
> Не, считаешь себя самой умной клавой на планете на манер кента. и что характерно — не просто так. и не я один. такой уж у меня недостаток: вижу глупость — и говорю, что это глупость. >> и что мне с этим значением делать? поясни, будь добр. я-то использую
>> `snprintf()` именно затем, чтобы он мне больше буфера не записал.
> Вообще, часто тот факт что truncate случился еще и внимния требует. Ибо
> есть шанс что получили не то что задумано. я очень рад про это «часто». но я спрашивю, что делать с этим *мне*. меня не интересуют общие рассуждения, я *знаю* что написал и зачем. идиома `snprintf(buf, sizeof(buf), "%s", str)` — очень удобный способ гарантированого обсечения строки по размеру буфера. да, меня даже не интересует, будет ли там в конце ноль: конкретно в этом месте мне оно неважно. хотя он там будет, так что даже в этом плане такой вызов *безопасен*. итак. зачем гоцэцэ сношает меня в мозг бесполезным ворнингом для операции, которая даже к формированию некорректной (не завершающейся нулём) строки привести не может? > Не, но зачастую факт truncate интересен - из соображений что в буфере
> не то что ожидалось. наверное, если бы мне это было интересно, я бы проверил возвращаемое значение. но я его не проверяю. может потому, что мне неинтересно? может потому, что это одна из стандартных сишных идиом? > Вот почему void так себя ведет хз, в принципе
> это можно и багом назвать. а авторы гоцэцэ это багом не считают. > Ну, заткнуть #pragma какой-нить. отлично. мы сделали очень полезный ворнинг, который нужно сайленсить. ты же понимаешь, почему повышение количества мусорных ворнингов понижает желание включать ворнинги и вчитываться в них в принципе? > Я тебя в всем этом нытье не пойму: я с учетом общего
> состояния дел за то чтобы antibug закрутить по максимуму. А ты
> можешь юзать свой GCC6 до опупения, соответственно. А я буду юзать
> - более секурный, стабильный и предсказуемый код. И вроде в такой
> схему все довольны. Не? кроме пользователей, которые почему-то недовольны. и программистов, которые почему-то недовольны и пишут в багтрекер гоцэцэ багрепорты, в которых авторы гоцэцэ поясняют, что это не баг, а для пользы написавших всё поломали. >> страшная ошибка, где тут угроза секурити? уж раз начал — то
>> будь любезен, поясни до конца. я с удовольствием поучусь.
> Угроза секурити? В буфере может быть не то что ожидал прогер ->
> прога может сделать не то что задумано. Это может быть и
> угрозой безопасности. Из определения вулнов от DJB. у меня начинает зарождаться подозрение, что если чуть-чуть развить твою логику, то идеальный компилятор — это который отказывается компилировать вообще любой код. ведь программа может делать не то, что задумал программист! опасно. всё-таки сколько тебе надо эквилибристики, лишь бы не признавать, что девелоперы гоцэцэ в очередной раз тупо профакапились и тоже не хотят этого признавать.
- Лично мне довольно пофиг - я в целом вполне могу жить с GCC и мне в общем нормал, Аноним (-), 20:46 , 28-Ноя-24 (364)
> …который авторы гоцэцэ багом не считают. к сожалению, соответствующий тикет в их
> багтрекере уже не найду: с какого-то момента я перестал сохранять примеры
> их идиотии.Лично мне довольно пофиг - я в целом вполне могу жить с GCC и мне в общем нормалек. Если даже порой какой винтажный код и приходится подкостылить для затыкания варнинга - ну, да, увы, мир не идеален, и делать из этого трагедию вселенского масштаба я не собираюсь. > скажи, а почему так получается: когда я про конкретную проблему веду речь
> — ты сразу перескакиваешь на общие рассуждения. а когда я про
> общие рассуждения — ты мгновенно отвечаешь, что тебе это неинтересно, что
> ты практик? Потому что как мне кажется - у нас разные цели и приоритеты. Мне интересно чтобы более-менее вписывалось в мои задачи и хотелки в целом - а мелкие неидеальности я так и быть обыграю. А вот крупные факапы требующие дохреналион человекочасов - без видимого output - я на себя взваливать, таки, без реально жесткой необходимости не буду. Что хочешь то с этим фактом и делай. > я тебе показал конкретную проблему. какое к ней отношение имеют рассуждения об
> анализаторах, о том, что «надо проверять значения, возвращаемые функциями»,
> вот это всё? Ну, показал и показал. Я разве сомневался что мир не идеален? Я и других тупняков показать могу, но больше всего у меня претензий - скорее к стандартизаторам. С точки зрения идей мне понравилось вообще как в Zig сделали, компилтайм вычисления тем же синтаксисом что и основная тушка. Это красивее навесных препроцессоров и макросов. Но в целом это такой дельтаплан с моторчиком - немного порассекать можно, но летать так чартерными рейсами все же не будешь. > в доказательствах (errare humanum est). опечатки компилятор иногда ловит, ошибки в
> доказательствах почему-то нет, даже с -Wall -Wextra -Wrealyreallyeverythingplease. И хрен с ним. Немало моих штук - эмпирика, и я ниипу как формально доказывать. Но я могу проверить поведение в реальных ситуациях, сделать fuzzing и посмотреть "what the worst it can do?". Как и просто оценить ожидаемое поведение алго. Де факто я просто предпочитаю делать реально критичные штуки - простыми. И иметь какой-то план на случай взбрыков и нестандартных ситуаций ("failsafe"). Реальный мир всегда может внести самые странные коррективы. Твой рафинированный академичный мозг порвало бы на части если бы ты увидел что предусматривают микроконтроллерщики в своем софте. Да, иной раз мы предусматриваем на серьезных щах "program counter runaway", битфлипы, неверные значения в параметрах и проч. Периодически релоадим критичные регистры - чтобы даже мощный EMI вызвал сбой управляющих сигналов лишь на короткое время максимум. Потому что если сделать дофига девайсов, раз в год в какой-то из будет попадать какая-нибудь высокоэнергетичная частица, какой-нибудь битик флипанется, и... в твоих доказательствах корректности такая фигня от реального мира - предусмотрена?! Или будет - как обычно у таких? Когда плана на этот случай у рафинированного академмозга оказывается - нет? И вот тут мы сильно разные в нашем восприятии мира. Между тем это все расскажет среднего пошиба safety critical firmware guide. Да, вот для си. > писать на языке валидные конструкции, которые языком разрешены — это не ошибка.
> или вся сишечка ошибка. одно из двух. Сишечка не идеальна, как и весь остальной мир. И нам придется с этим жить. Я научился жить с этими неидеальностями. Я даже могу жить в допущении что раз в год в проц прилетает частица (или какой там ломовой EMI от молнии рядом) - и он творит дичь, прикинь?! И даже предусмотреть рекавери, если оно электрически вообще еще в состоянии. > проблему «у меня не помещается на флэшину» я буду решать тогда,
> когда она у меня будет. Подозреваю что она у тебя не будет - никогда. Ибо ты на это не похож. Мы видим мир под довольно разным углом. > хотел написать в моей программе. при этом на `+` они отчего-то
> не ругаются — а это опасная операция, которая может привести к
> UB со знаковыми целыми! Это кто тебе сказал что они не ругаются? Ты просто -Wconversion в своем коде не пробовал кажись. Попробуй, узнаешь много нового. Это если что из советов Cyan (автор LZ4) взято. > сыпет всё больше бесполезных мусорных ворнингов, при этом продолжая игнорировать реальные
> ошибки, из-за которых происходит основная масса проблем. Не подтверждаю. Благодаря агрессивным варнингам придушил пару потенциальных проблем, и так то я билдую довольно много разного софта. > принесёт ветром в пустые черепа разработчиков гоцэцэ в следующий раз, и
> что они решат сломать. Лично с моей стороны переход на новые GCC мне пришелся вполне по вкусу, агрессивные варнинги это то что я хотел. Да, ложняки иногда бывают. Да, порой это кого-то подбешивает. С другой стороны я успешно прибил благодаря этому несколько стремноватых мест в коде где стремноватые места не хотелось бы. > кстати, пользуясь случаем передаю привет и авторам binutils, которые в одном из
> *официально* *выпущеных* релизов умудрились сломать конструкторы статических объектов
> в крестах (и, кажется, атрибут constructor в gnuc тоже). это не
> «мелкий баг», как ты понимаешь. Теперь и ты понимаешь что такое "валидация тулчейна". Да, несомненно, до того как я начну доверять тулчейну что-то реально критичное - я основательно тестирую все это хозяйство на своем коде. Де факто я в каком-то я полюбил нечто типа Test Driven. Я никому не верю, особенно себе, и вседа проверяю что код делает и правда то что задумано, проверив что логика и правда та что я задумал. Это неплохо работает и спасает от множества горя при умеренных затратах времени. > и не мои, конечно, потому что я сообщаю, что гоцэцэ выше шестого
> официально не поддерживается. Ну а для меня это гарантия что я никогда не рассмотрю такой проект как апстрим. Т.е. это для меня сразу - индикатор. И он мне говорит что с этими людьим я дел не имею в принципе. Если кто хочет спорить со всем миром - это прекрасно. Но у большей их части совершенно нет плана на случай если "мир оказался сильней". А это довольно вероятный расклад. И применяя вон те околобайесовские стили решений - это лучше обойти за километр, чтобы потом не было мучительно больно. > ага. и ещё кучи народа. пипол периодически пытается найти у авторов гоцэцэ Вопрос в соотношениях. А семеро одного таки не ждут, и best practices, таки, изменились. Читай cyan. Твой код хотя-бы -Wconversion переживает чтобы мне тут о доказательствах задвигать? Да, это те promotions и проч на которые gcc якобы-не-умеет варнинги. Ващет умеет, вот только готов ли твой "супер кот" к такому? > поскольку я пишу на сишечке или примерно как на обероне, или код,
> который ни один анализатор не понимает И это еще +1 антипаттерн. Хотя справедливости ради - я недавно таки смог разок вынести череп cppcheck'у случайно :). Но вообще-то это скорее всего означает что...
1) Это не подлежит майнтенансу.
2) Там скорее всего более 9000 багов которые ты не заметил. И конечно ни для каких критичных применений такой код ни-ни. > анализаторов. за годы и годы это нашло несколько мелких ошибок, и
> огромные портянки false positives. У нормальных людей все ровно наоборот, но если кто принципиально решил ссать против ветра - я не понимаю, почему он жалуется на ветер и мокрые штаны. > обсечение в `snprintf()`, несомненно, намного опасней и источник намного большего количества
> багов ирл. поэтому валидный код с `snprintf()` мы будем ругать, массивы
> мелочь, не стоят внимания. Вон то халявное - в компилтайме чекается. Массивы - фиг вам, надо рантайм проверки, при том местами весьма дорогие. Но между нами у меня есть софт который с ubsan даже в проде. И тут ты такой рассказываешь мне как это "невозможно". Да, для тебя в GCC6 может, конечно, и невозможно - я не помню, был там ubsan вообще? Впрочем если меня сильно такое парит - это оказывается контейнер. В виртуалке. И даже если там внешний злыдень все разнесет - то что? Даже если ты вот тут получишь рут - тебе все равно ничего кроме Downloads этого браузера не достанется. Task specific VM, и только. > как-то надёжно — пересоберите с этим флагом весь мир. и плевать,
> что он у вас даже не соберётся. Если ты хотел быть интегратором/wrangler'ом и проч - те знали на что шли. Их судьба сталкиваться с неидеальностями мира и пытаться это утрясти. Это не для слабых духом. А если ты решил это скосплеить но рафинированный мозг оказался для жестокого реального мира слишком мягкотелым - при чем тут я? > когда факапы случаются регулярно, и авторы не желают признавать, что это факапы,
> считая себя самыми умными на планете… что ты про кента писал, а? ;-) При разработке софта факапы случаются - почти всегда и везде. В основном потому что люди довольно глючные и забагованые существа. Исключение - hello world. Собссно это и есть причина разбивать сложные таски на простые, и делать скажем критичные фирмвари - dead simple. А так - вопрос в масштабе и "управлении рисками". >> Игнор возврата функций которые что-то возвращали - отличный индикатор факапов и багов.
> почему тогда гоцэцэ не ругается при тех же настройках на *все* случаи
> такого игнора? Ээээ вообще, по нормальному как раз должен. Но я не знаю что там за настройки и код. > знаешь, или трусы, или крестик. оберон, например, просто не
> скомпилирует программу, в которой функция вызывается как процедура. Он мне фирмварь для вон тех мк (несколько разных выводков) вообще никак не скомпилирует в отличие от GCC. Остальное при этом мне уже не так уж и важно. > на x86 — в районе zero cost. одно cmp, один бранч, который
> в подавляющем большинстве случаев not taken. Даже на x86 это зачастую оказывается не zero cost. А вполне заметный шмат кода и ощутимый факап производительностии. Но как я уже сказал - пока ты ныл, я гонял код с -fsanitize=undefined который как раз сие - ловит. Для полного анализа динамических аллокаций, конечно, asan надо. А вот тут сишка реально дотнетом станет, увы. > про армы — значит, и я могу аргументировать x86-архитектурой. Я гонял всякие бенчи с ubsan. Это приемлимо. Иногда. Но оверхед на практике таки совсем не нулевой обычно. Особенно в tight loop каких и проч. > и что характерно — не просто так. и не я один. такой
> уж у меня недостаток: вижу глупость — и говорю, что это глупость. И так то без таких людей мир был бы довольно скучен. Но это заведомое и сильное усложнение жизни себе. Я просто научился контролировать этот эффект - и юзать его себе во благо. Некоторые законы природы лучше работают если условие изменить или проинвертировать. Как, вот, теорвер, бэды и DUP. Теперь я проигрываю не если "вылез 1 бэд" [под чем-то критичным] а - если 2 бэда накрыли 1 логическое смещение 2 копий в физически разных местах. Это уже - произведение вероятностей, и вот так теорвер - гораздо прикольнее, я проверял :) > и зачем. идиома `snprintf(buf, sizeof(buf), "%s", str)` — очень удобный способ
> гарантированого обсечения строки по размеру буфера. да, меня даже не интересует, Ну, какой-нибудь #pragma воткнуть в этом месте, зарубив варнинг? Костыль, конечно, что скажешь. > итак. зачем гоцэцэ сношает меня в мозг бесполезным ворнингом для операции, которая
> даже к формированию некорректной (не завершающейся нулём) строки привести не может? Потому что в целом эта операция может привести к содержимому иному чем ожидалось - и готов ли к этому дальнейший код - отдельный вопрос. > наверное, если бы мне это было интересно, я бы проверил возвращаемое значение. Вообще-то забыть такое - один из типовых багов как раз. С ним и заруб. > потому, что это одна из стандартных сишных идиом? Не помню чтобы стандарты поощряли игнор кодов возврата функций. В любом случае ТАКОЕ - well known источник массовых багов. > а авторы гоцэцэ это багом не считают. - А чем Фурманов это мотивировал?
- Ух василь иваныч, как он мативировал! И меня, и вас! (а чем они это мотивировали? и что предлагали?) > отлично. мы сделали очень полезный ворнинг, который нужно сайленсить. ты же понимаешь, Да, я понимаю что локально засайленсить 1 ложняк в 1 закоулке - меньшее зло чем не делать проверку таких вещей по площадям и наслаждаться ... тем что мы де факто получем в сишном коде, сотни багов, глюков, CVE и проч. Реальности изменились, tradeoffs - тоже. И теперь стандарты кодинга стали жестче. Раздолбаить стало непочетно. А кому не нравится - вылетит на задворки истории. И не то чтобы я буду скучать, ибо - вон то несколько утомило, при всем уважении, с этим пора что-то сделать. И это именно то самое. Расчистка барахла по площадям. Даже если и с ложняками иногла. > почему повышение количества мусорных ворнингов понижает желание включать ворнинги и
> вчитываться в них в принципе? К счастью это выступает надежным детектором отношения и чьим именно софтом пользоваться не надо. Так что я видя такие полися могу быстро сделать информированный выбор что мне с таким проектом и его отношением к качеству кода не по пути. По моему так всем хорошо, а? Ты прогаешь на своем GCC6, я вижу это за световой год и обхожу соседней галактикой как потенциальный склад багов, глюков и вулнов. И по моему все счастливы, не? > кроме пользователей, которые почему-то недовольны. и программистов, которые почему-то
> недовольны и пишут в багтрекер гоцэцэ багрепорты, в которых авторы гоцэцэ
> поясняют, что это не баг, а для пользы написавших всё поломали. В этом мире при достаточно большой программе - и числе юзерей - всегда кто-то чем-то недоволен. Что ж теперь, программы не релизить? Вопрос в соотношениях. Если полпланеты землю копытом роет, вероятно вышел перегиб. Но де факто ты первая тушка с такой претензией на моем пути. Т.е. масштаб эффекта для меня выглядит - мизерным. А улучшени фич статического анализа и проч я очень одобряю. Это позволяет делать мне более качественный в целом код. > у меня начинает зарождаться подозрение, что если чуть-чуть развить твою логику, то
> идеальный компилятор — это который отказывается компилировать вообще любой код. Не, идеальный - это коотрый все факапы в compile time просекает. Но это, увы, чисто технически невозможно, даже теоретически. Начиная с того что изначальная идея в моем мозгу могла быть далеко не лучшей из возможных и иметь какой-то изъян в ее логике. > ведь программа может делать не то, что задумал программист! опасно. всё-таки
> сколько тебе надо эквилибристики, лишь бы не признавать, что девелоперы гоцэцэ
> в очередной раз тупо профакапились и тоже не хотят этого признавать. Багов бояться - софт не девелопать. И да. Перетрясы тулчейна я предпочитаю делать лишь иногда - с возможностью отыграть назад - и валидацией результата. Т.е. я вполне готов столкнуться с неидеальнстями реального мира, и предпочитаю чтобы был Plan B, C и даже D, а может и еще какой, если вдруг надо.
- ну, кто-то молча хавает что дали, а кто-то не хочет это всё отлично но совершен, arisu (ok), 22:00 , 28-Ноя-24 (365)
> Лично мне довольно пофиг - я в целом вполне могу жить с
> GCC и мне в общем нормалек. Если даже порой какой винтажный
> код и приходится подкостылить для затыкания варнинга - ну, да, увы,
> мир не идеален, и делать из этого трагедию вселенского масштаба я
> не собираюсь.ну, кто-то молча хавает что дали, а кто-то не хочет. >> скажи, а почему так получается: когда я про конкретную проблему веду речь
>> — ты сразу перескакиваешь на общие рассуждения. а когда я про
>> общие рассуждения — ты мгновенно отвечаешь, что тебе это неинтересно, что
>> ты практик?
> Потому что как мне кажется - у нас разные цели и приоритеты.
> Мне интересно чтобы более-менее вписывалось в мои задачи и хотелки в
> целом - а мелкие неидеальности я так и быть обыграю. это всё отлично. но совершенно не отвечает на вопрос, который я задал. >> я тебе показал конкретную проблему. какое к ней отношение имеют рассуждения об
>> анализаторах, о том, что «надо проверять значения, возвращаемые функциями»,
>> вот это всё?
> Ну, показал и показал. Я разве сомневался что мир не идеален? Я
> и других тупняков показать могу, но больше всего у меня претензий
> - скорее к стандартизаторам. это всё отлично. но совершенно не отвечает на вопрос, который я задал. > И хрен с ним. Немало моих штук - эмпирика, и я ниипу
> как формально доказывать. типичная гордость гуанокодера-недоучки, прости. я-то всегда думал, что гордиться качествами, которые свидетельствуют о профнепригодности — не самая лучшая идея… > и просто оценить ожидаемое поведение алго. не можешь. ты не понимаешь, как он работает — ровно это ты выше сам написал. > Твой рафинированный академичный мозг порвало бы на части если бы ты увидел
> что предусматривают микроконтроллерщики в своем софте. мой рафинированый академичный мозг применялся в том числе и для написания софта для контроллеров. ещё во времена восьмибиточек. да и софт, работающий на ядрёных станциях, я знаю не по наслышке.
>> или вся сишечка ошибка. одно из двух.
> Сишечка не идеальна, как и весь остальной мир. И нам придется с
> этим жить.
ну, живите, кто ж запрещает. меня просто умиляет нежелание видеть ничего другого. забавно палочкой потыкать. >> проблему «у меня не помещается на флэшину» я буду решать тогда,
>> когда она у меня будет.
> Подозреваю что она у тебя не будет - никогда. я уж постараюсь. но спасибо за столь высокую оценку моих скилов.
>> хотел написать в моей программе. при этом на `+` они отчего-то
>> не ругаются — а это опасная операция, которая может привести к
>> UB со знаковыми целыми!
> Это кто тебе сказал что они не ругаются? Ты просто -Wconversion в
> своем коде не пробовал кажись.
ты даже не понял, о чём я. при чём тут implicit conversions? ты стандарт своей любимой сишечки-то читал? в курсе, что переполнение целых со знаком — UB? в курсе, что `int foo (int a, int b) { return a + b; }` — это security vulnerability? почему компилятор не предупреждает о такой вопиющей дыре? > Теперь и ты понимаешь что такое "валидация тулчейна". я только не понимаю, почему это должны делать конечные пользователи, натыкась на баг, который вообще не должен был прожить дольше максимум одного коммита. хотя там, наверное, тоже не могут свои алгоритмы доказать… > Де факто я в каком-то я полюбил нечто типа Test Driven. Я
> никому не верю, особенно себе, и вседа проверяю что код делает
> и правда то что задумано, проверив что логика и правда та
> что я задумал. Это неплохо работает и спасает от множества горя
> при умеренных затратах времени. спасибо, что рассказал мне, что такое тесты. откуда ж мне знать-то было… >> и не мои, конечно, потому что я сообщаю, что гоцэцэ выше шестого
>> официально не поддерживается.
> Ну а для меня это гарантия что я никогда не рассмотрю такой
> проект как апстрим. фильтр работает как задумано. > Если кто хочет спорить со всем миром - это прекрасно. Но у
> большей их части совершенно нет плана на случай если "мир оказался
> сильней". это их личные проблемы. >> ага. и ещё кучи народа. пипол периодически пытается найти у авторов гоцэцэ
> Вопрос в соотношениях. А семеро одного таки не ждут, и best practices,
> таки, изменились. Читай cyan. «как есть гуано чтобы не очень заляпаться», руководство. спасибо, но я предпочитаю не есть гуано. > Твой код хотя-бы -Wconversion переживает чтобы мне
> тут о доказательствах задвигать? Да, это те promotions и проч на
> которые gcc якобы-не-умеет варнинги. то есть, ты точно совершенно не понял, о чём я писал выше. ты и сишечки-то не знаешь, что ли? > Ващет умеет, вот только готов ли твой "супер кот" к такому? мой код много к чему готов. к сожалению, вместо делать дело — приходится иногда тратить время на ублажение компилятора. >> поскольку я пишу на сишечке или примерно как на обероне, или код,
>> который ни один анализатор не понимает
> И это еще +1 антипаттерн. давай, расскажи мне, как ты пишешь для контроллеров строго-строго соблюдая весь стандарт си. первым в мире будешь, крутая ачивка. анализаторы — тупые. не могут понять сложный алгоритм, где я доказал времена жизни всех объектов, и поэтому могу, например, довольно хитро работать с указателями на локальные объекты. компилятор, кстати, тоже зудит не по делу. но в этом случае я снисходителен. > Но вообще-то это скорее всего означает что...
> 1) Это не подлежит майнтенансу.
> 2) Там скорее всего более 9000 багов которые ты не заметил. и никто за много лет не заметил. ни в доказательствах, ни в рабочей программе. я-то понимаю, как работают мои алгоритмы. > И конечно ни для каких критичных применений такой код ни-ни. ничего, применяю. пока что никто не взорвался и не помер. >> анализаторов. за годы и годы это нашло несколько мелких ошибок, и
>> огромные портянки false positives.
> У нормальных людей все ровно наоборот да знаю я, знаю, что «нормальные люди» считают достоинством не уметь в программирование. зачем они при этом занимаются тем, во что принципиально не хотят уметь — для меня до сих пор загадка. >> обсечение в `snprintf()`, несомненно, намного опасней и источник намного большего количества
>> багов ирл. поэтому валидный код с `snprintf()` мы будем ругать, массивы
>> мелочь, не стоят внимания.
> Вон то халявное - в компилтайме чекается. и выдаёт false positive, потому что в двух третях случаев никакого обсечения быть не может. да, я это доказал. > Но между нами у меня есть софт который с ubsan даже в
> проде. всегда приятно читать, как люди гордятся тем, что *иногда* выпускают софт с проверками надёжности. такая редкая штука, что стоит особого упоминания. > Впрочем если меня сильно такое парит
> - это оказывается контейнер. В виртуалке. И даже если там внешний
> злыдень все разнесет - то что? квинтэссэнция современного «девелопинга». > Если ты хотел быть интегратором/wrangler'ом и проч - те знали на что
> шли. спасибо, не хотел. > А если ты решил это скосплеить но рафинированный мозг оказался для жестокого
> реального мира слишком мягкотелым - при чем тут я? да не при чём. просто усердно меня убеждаешь, что простейшие проверки — это очень, очень сложно. прелестный мир сишечки. > При разработке софта факапы случаются - почти всегда и везде. В основном
> потому что люди довольно глючные и забагованые существа. Исключение - hello
> world. Собссно это и есть причина разбивать сложные таски на простые,
> и делать скажем критичные фирмвари - dead simple. только некоторые их признают, а некоторые — нет. авторы гоцэцэ предпочитают не признавать. >>> Игнор возврата функций которые что-то возвращали - отличный индикатор факапов и багов.
>> почему тогда гоцэцэ не ругается при тех же настройках на *все* случаи
>> такого игнора?
> Ээээ вообще, по нормальному как раз должен. Но я не знаю что
> там за настройки и код. -Wall. что-то не ругается. видимо, это не настолько важная штука, как ты мне пытаешься доказать. по крайней мере с точки зрения авторов гоцэцэ. зато легальный и безопасный вызов `snprintf()` — очень, очень опасная. >> знаешь, или трусы, или крестик. оберон, например, просто не
>> скомпилирует программу, в которой функция вызывается как процедура.
> Он мне фирмварь для вон тех мк (несколько разных выводков) вообще никак
> не скомпилирует в отличие от GCC. тоже мне проблема. ну, сделаю новый бэкэнд к компилятору — дело нехитрое. во что надо — в то финальный SSA и спою. >> на x86 — в районе zero cost. одно cmp, один бранч, который
>> в подавляющем большинстве случаев not taken.
> Даже на x86 это зачастую оказывается не zero cost. мой компилятор оберона говорит, что статистически мало отличимо от zero cost. такая вот столь любимая тобой практика. > пока ты ныл, я гонял код с -fsanitize=undefined а я просто сделал себе компилятор оберона — как мне нравится — и использую его. с проверками NIL dereference, с bounds checking, с overflow checking. удобно. > раз сие - ловит. Для полного анализа динамических аллокаций, конечно, asan
> надо. А вот тут сишка реально дотнетом станет, увы. представляешь — даже ужасный GC использую. удобно. а иногда не использую. а иногда и использую, и не использую. > Я гонял всякие бенчи с ubsan. Это приемлимо. Иногда. Но оверхед на
> практике таки совсем не нулевой обычно. Особенно в tight loop каких
> и проч. хвалёный gcc не умеет в symbolic analysis, и не может доказать, что в цикле проверка не нужна, потому что out-of-bounds никогда не будет? ну ой. > И так то без таких людей мир был бы довольно скучен. Но
> это заведомое и сильное усложнение жизни себе. я не всегда ищу самый лёгкий путь. иногда предпочитаю *правильный*. >> и зачем. идиома `snprintf(buf, sizeof(buf), "%s", str)` — очень удобный способ
>> гарантированого обсечения строки по размеру буфера. да, меня даже не интересует,
> Ну, какой-нибудь #pragma воткнуть в этом месте, зарубив варнинг? Костыль, конечно, что
> скажешь. я очень много чего сказал, когда на это наткнулся. впрочем, из приличных слов там были только паузы. хотя и те отдавали матерком. >> итак. зачем гоцэцэ сношает меня в мозг бесполезным ворнингом для операции, которая
>> даже к формированию некорректной (не завершающейся нулём) строки привести не может?
> Потому что в целом эта операция может привести к содержимому иному чем
> ожидалось - и готов ли к этому дальнейший код - отдельный
> вопрос. повторю: почему оно не реагирует на `+`? в отличие от `snprintf()` — плюс с целыми знаковыми может привести к UB. потому что ключи ищут не там, где потеряли, а там, где светло? >> наверное, если бы мне это было интересно, я бы проверил возвращаемое значение.
> Вообще-то забыть такое - один из типовых багов как раз. С ним
> и заруб. отлично. я написал `(void)snprintf(…)`. почему оно не заткнулось? почему такое вообще попало в официальный релиз? гоцэцэ совсем перестали тестировать? ну, я бы не удивился. >> потому, что это одна из стандартных сишных идиом?
> Не помню чтобы стандарты поощряли игнор кодов возврата функций. В любом случае
> ТАКОЕ - well known источник массовых багов. см. выше про `+`. >> а авторы гоцэцэ это багом не считают.
> а чем они это мотивировали? Потому Что. > и что предлагали?) добавить проверку, и сделать в ней… ну, что нибудь, нам неинтересно, что вы там делать будете. но что-нибудь такое, чтобы компилятор ваш `if` не убрал, а то ворнинг обратно выскочит. короче, займитесь ублажением компилятора, нам плевать на ваши проблемы. >> отлично. мы сделали очень полезный ворнинг, который нужно сайленсить. ты же понимаешь,
> Да, я понимаю что локально засайленсить 1 ложняк в 1 закоулке у меня довольно много таких вызовов. и я не вижу никакой необходимости делать для них дурацкий бесполезный врапер. более того: если я хорошо врапер аннотирую — ворнинг вылезет уже на нём. а если не аннотирую — потеряю, например, проверки форматной строки. спасибо, очень удобно, всю жизнь о такой фиче мечтал. > тем что мы де факто получем в сишном коде,
> сотни багов, глюков, CVE и проч. см. выше про `+`. > Реальности изменились, tradeoffs - тоже. И теперь стандарты кодинга стали жестче. а программирования — остались какими были. > Раздолбаить стало непочетно. пчёлы против мёда. > Расчистка барахла по площадям. ой, а кто же там намусорил-то? >> почему повышение количества мусорных ворнингов понижает желание включать ворнинги и
>> вчитываться в них в принципе?
> К счастью это выступает надежным детектором отношения и чьим именно софтом пользоваться
> не надо. Так что я видя такие полися могу быстро сделать
> информированный выбор что мне с таким проектом и его отношением к
> качеству кода не по пути. ну да. судя по твоему описанию твоих практик — я бы, скорее всего, твои патчи не принял. так что ты, в принципе, прав. ;-) > Если полпланеты землю копытом роет, вероятно …проект, наконец, дозрел. > де факто ты первая тушка с такой претензией на моем пути. потому что большинство людей или молча жрут то, что им скармливают авторы гоцэцэ (ты тут уже который пост мне доказываешь, что надо жрать и благодарить за тёплую шапку), или — меньшинство — уже имели опыт взаимодействия с гоцэцэ-дивилаперами, и больше не хотят. это самое меньшинство, кстати — обычно совпадает с множеством людей, которые действительно понимают в том числе и внутреннюю механику, и не боятся компиляторов, кодогенов и асмов. > Т.е. масштаб эффекта для меня выглядит - мизерным. А улучшени фич
> статического анализа и проч я очень одобряю. Это позволяет делать мне
> более качественный в целом код. гуанокод. > Багов бояться - софт не девелопать. продолжение квинтэссэнции современного «девелопинга».
- Скрыто модератором, Аноним (-), 18:41 , 03-Дек-24 (375) [---]
>> мир не идеален, и делать из этого трагедию вселенского масштаба я не собираюсь.
> ну, кто-то молча хавает что дали, а кто-то не хочет.И из трезвых рациональных предложений лучше чем это, будет, например, что? Извини, маргинальные вещи меня не интересуют - ибо переписывать весь софт на планете в мои планы не входит. Это mission impossible. Если ты хочешь показать обратное - окей, покажи как ты лихо девелопаешь печатки на уровне хотя-бы не хуже KiCad? Да, я хочу дожить до момента когда проприетарные боги делающие компы, уровня годного под мой воркстейшн - пойдут нафиг, прикинь?! >> Мне интересно чтобы более-менее вписывалось в мои задачи и хотелки в
>> целом - а мелкие неидеальности я так и быть обыграю.
> это всё отлично. но совершенно не отвечает на вопрос, который я задал. Вероятно дело в том что для меня те проблемы не выглядят чем-то фатальным. Да, они есть. Но в моей системе приоритетов это что-то на уровне "анноянса". То-есть я могу с этим жить, и это особо не нагибает достижение целей в конечном итоге. А эстетство и чистоплюйство - нагибает достижение целей жесточайше. Встречный вопрос: как так получается, когда я прошу показать мне конкретные проблемы от CRC32 как функции хеширования в btrfs, для меня, в сценариях практикуемых мной, я не получаю ничего кроме столь же общих бла-бла? Видишь, кэп, в эту игру могут играть и двое. > это всё отлично. но совершенно не отвечает на вопрос, который я задал. Я попытался объяснить мое мышление. Не знаю то ли это что ты хотел - но - как есть. За тобой ровно такой же failure mode тоже водится. > типичная гордость гуанокодера-недоучки, прости. я-то всегда думал, что гордиться качествами,
> которые свидетельствуют о профнепригодности — не самая лучшая идея… В этом мире засчитываются - решения которые есть и работают. Рассуждать про правильное устройство ФС юзая крап типа FFS и фатов мне "не очень". И я вместо этого буду юзать btrfs. Потому что он дает моим дизайнам новые свойства, желательные в вон тех задачах. И сам я соответственно тоже буду действовать - в примерно таком же ключе. Оптимизируя активность на реальное решение задач и достижение целей а не чистоплюйство, которое - приятный бонус, если прокатило, не более. >> и просто оценить ожидаемое поведение алго.
> не можешь. ты не понимаешь, как он работает — ровно это ты выше сам написал. Вообще-то когда меня интересует - я и более-менее понимаю, и наконец - могу просто померять типовые ворклоады. И отправить теоретиков в пень. > мой рафинированый академичный мозг применялся в том числе и для написания софта
> для контроллеров. ещё во времена восьмибиточек. да и софт, работающий на
> ядрёных станциях, я знаю не по наслышке. Мне все равно. Я делаю несколько более приземленные управляюшие штуки. Это другие кейсы, с другими соотношениями. И там примерно те отраслевые практики, которым я и следую. И да, сишку можно - вот - в весьма safety critical. Если не идиотничать. А програминг софта для АЭС в мои планы - таки - не входит. Как и работа в подобных структурах, упаси меня. И толстых котов за моей спиной нет чтобы фигней страдать без результата. > ну, живите, кто ж запрещает. меня просто умиляет нежелание видеть ничего другого.
> забавно палочкой потыкать. Тыкать палочкой имеет смысл если ты мог предъявить что-то лучше. Но с этим не судьба. Или где например ФС лучше от тебя после наездов на btrfs? Не, такая штука в 1 фэйс до ума не доводится, как максимум лабораторный макет получится. >>> проблему «у меня не помещается на флэшину» я буду решать тогда, когда она у меня будет.
>> Подозреваю что она у тебя не будет - никогда.
> я уж постараюсь. но спасибо за столь высокую оценку моих скилов. Было бы круто если правда. Но я бы не удивился узнав что ты отлепляешь зад и идешь к выключателю, смотришь на градусник за бортом сам, etc. И если так, боюсь, подтверждает идею "детектора паттернов" - сапожника без сапог. А вот интересно - правильно подтверждает? Или сэр програмивший все вон то - все же без сапог не отвисает? Не пытайся меня обмануть, по ряду причин это не получится. > ты стандарт своей любимой сишечки-то читал? в курсе, что переполнение целых
> со знаком — UB? Я в курсе. И поэтому люблю - нормальные типы из C99 с гарантированной шириной и unsigned, где переполнение - well defined behavior. И уж конечно я анализирую размерность операций при написании кода. > в курсе, что `int foo (int a, int b) { return a + b; }` — это security
> vulnerability? Спасибо кэп. Но vulnerability только в определенных случаях. Но вот за такое я дидов и не жалую. > почему компилятор не предупреждает о такой вопиющей дыре? Вот это хороший вопрос. Наверное потому что ложняков с кодом от дидов пихавшими этот "int" везде - будет чуть менее чем весь код. Ubsan однако такое на раз ловит. >> Теперь и ты понимаешь что такое "валидация тулчейна".
> я только не понимаю, почему это должны делать конечные пользователи, натыкась на
> баг, который вообще не должен был прожить дольше максимум одного коммита.
> хотя там, наверное, тоже не могут свои алгоритмы доказать… Ну вот нету там гениев типа тебя, они и играют как умеют. А сапожники отвисают без сапог, ничего нового. > спасибо, что рассказал мне, что такое тесты. откуда ж мне знать-то было… Ну а что, это моя очередь покапитанить была. Я как раз люблю всякие краевые случаи, ибо чужой код на этом часто валится. >> Ну а для меня это гарантия что я никогда не рассмотрю такой проект как апстрим.
> фильтр работает как задумано. У нас тут кажется консенсус, как ни странно :). Экономит время и тебе и мне. > это их личные проблемы. Хочешь сказать что с тобой так не бывает? > «как есть гуано чтобы не очень заляпаться», руководство. спасибо, но я предпочитаю
> не есть гуано. Угу, и в результате - учишься фотосинтезировать, но, кажется, не очень мощно пока получается. > то есть, ты точно совершенно не понял, о чём я писал выше.
> ты и сишечки-то не знаешь, что ли? Таки знаю. Если про переполнения signed в вон том случае - таки, да, это только ubsan ловится. Но я плохо представляю себе как это варнингом делать, с кодом от дидов тогда вообще все будет варнингами сыпать. Варнинги по всей площади ведут только к тому что на них забивают. Де факто даже (signed int) i++ может ведь быть UB. Вопрос в том чему i сейчас равно. А такой код чуть менее чем везде. Это что на каждый цикл for от дидов - орать? >> Ващет умеет, вот только готов ли твой "супер кот" к такому?
> мой код много к чему готов. к сожалению, вместо делать дело —
> приходится иногда тратить время на ублажение компилятора. Вот тут я согласен, может и анносить временами. На ублажение анализаторов тоже порой приходится. > давай, расскажи мне, как ты пишешь для контроллеров строго-строго соблюдая весь стандарт
> си. первым в мире будешь, крутая ачивка. Таки - увы - полностью не соблюдаю, как минимум размещение объекта в конкретную секцию будет нестандартно, а без этого таблица векторов в нужную физическую локацию бинаря таки не попадет, плюс всякие вещи типа стартапа совсем стандартно by design не делаются. > анализаторы — тупые. не могут понять сложный алгоритм, где я доказал времена
> жизни всех объектов, и поэтому могу, например, довольно хитро работать с
> указателями на локальные объекты. компилятор, кстати, тоже зудит не по делу.
> но в этом случае я снисходителен. Ты что, сделал почти-хруст прямо из сишки? Я видел такое на плюсоте, но там гибкости яп хватило на косплей части коснтрукций хруста прямо плюсами. Заоверлоадили "operator []" в основном и сделали подобие логики борова. > и никто за много лет не заметил. ни в доказательствах, ни в
> рабочей программе. я-то понимаю, как работают мои алгоритмы. Это представляет ценность только для тебя. А для остальных этот код - одно большое минное поле. Особенно при попытке что-то там поменять. В общем жесточайший антипаттерн. И говоря за стандарты - такое вероятно не пройдет какой-нибудь MISRA чекер, и - поделом. >> И конечно ни для каких критичных применений такой код ни-ни.
> ничего, применяю. пока что никто не взорвался и не помер. Я б вообще в критичном коде указатели лишний раз трогать не стал. Кроме может каких указателей на кастомные struct, где тип форсится достаточно жестко и облажаться довольно сложно. > да знаю я, знаю, что «нормальные люди» считают достоинством не уметь в
> программирование. зачем они при этом занимаются тем, во что принципиально не
> хотят уметь — для меня до сих пор загадка. Во первых, программирование обычно лишь цель в достижении энных задач.
Во вторых, если все шагают не в ногу с твоим величеством, это наводит на определенные мысли. >> Вон то халявное - в компилтайме чекается.
> и выдаёт false positive, потому что в двух третях случаев никакого обсечения
> быть не может. да, я это доказал. Вот ты накаркал блин, мне он как раз понадобился. И конечно с контролем что - урезалось. Ибо это ошибка ожидаемого формата. > всегда приятно читать, как люди гордятся тем, что *иногда* выпускают софт с
> проверками надёжности. такая редкая штука, что стоит особого упоминания. Тебе не приходило в голову что это сильно зависит от характера софта? Скажем если его внешний мир в виде сети долбит недоверяемыми данными - одно, а если это процессинг моих локальных доверяемых данных, нет никакого смысла гробить время проца на проверки которые "always false". >> злыдень все разнесет - то что?
> квинтэссэнция современного «девелопинга». Квинтэссенция современной инженерии: оптимизация bang per buck. Ну или в данном случае - потратить минимум своих сил, создав максимум проблм атакующему. Заметь, при этом мне вообще не важно где будет лажа, урон минимизирован во ВСЕХ случаях. Даже какая-то логическая ошибка в дизайне программы - ни к чему такому не приведет. Ну вот допустим тут ты как максимум сопрешь downloads моего браузера. Которые я из интернета скачал. А все диверсии - независио от их природы - будут аннулированы откатом снапшота. Это машина времени, и вас в той точке таймлайна не стояло. > спасибо, не хотел. Ну и не будь. Таким как я больше достанется. > да не при чём. просто усердно меня убеждаешь, что простейшие проверки —
> это очень, очень сложно. прелестный мир сишечки. Это не "сложно" но
1) Дрфига унаследованного кода от раздолбаев.
2) Ряд проверок не халявны по скорости в рантайме. >> При разработке софта факапы случаются - почти всегда и везде. ...
> только некоторые их признают, а некоторые — нет. авторы гоцэцэ предпочитают не
> признавать. Вот не скажи, я знаю и примеры признания ими багов. > -Wall. что-то не ругается. видимо, это не настолько важная штука, как ты
> мне пытаешься доказать. по крайней мере с точки зрения авторов гоцэцэ.
> зато легальный и безопасный вызов `snprintf()` — очень, очень опасная. Так у вон того return a+b для signed тоже так то были легитимные, безопасные применения. С фига такие двойные стандарты? При том кажется у нас обоих. > тоже мне проблема. ну, сделаю новый бэкэнд к компилятору — дело нехитрое.
> во что надо — в то финальный SSA и спою. В мои цели так по жизни вообще совсем не входит написание бэкэндов компиляторов. > мой компилятор оберона говорит, что статистически мало отличимо от zero cost. такая
> вот столь любимая тобой практика. Угу, от сишки то с lto? Что-то мне кажется, что кой-кто мне в лучшем случае говорит не всю правду, на манер майкрософт. >> пока ты ныл, я гонял код с -fsanitize=undefined
> а я просто сделал себе компилятор оберона — как мне нравится —
> и использую его. с проверками NIL dereference, с bounds checking, с
> overflow checking. удобно. 1) Null deref полностью проверить при компиле в произвольном виде невозможно. Ибо откуда ты заранее знаешь какой я адрес захочу влупить указателю там или тут произвольными вычислениями? 1a) У меня был и ЛЕГИТИМНЫЙ повод выставить указатель 0, ибо я хотел - значение по адресу 0. Фирма ARM, однако, была иного мнения, и как оказалось - форснула ЭТО в хардваре даже в мк. В результате бутлоадер пришлось писать с костылями. Там у Cortex M дефолт для SP хранится и корябая re-entry, я его узнать хотел. Почему-то.
3) Я могу запустить фирмвару с минимальным ubsan, только вот это ни в раз не халявно и стоит мне треть перфоманса в интенсивных алго и четверть флехи. И в отличие от сферических бла-бла про zero cost я это все еще и измерить смог. Потому что могу и с этим, и без. На вполне конкретной real-world фирмваре. А ты, говоря про zero cost, так же сможешь вообще? Или джентльменам предлагается - верить на слово? Как твой "zero" cost измерен? В моем случае пуском с фичой и без. Да, в дебаг режиме той фирмвари у меня было несколько бенчей ключевых алго. Или к вопросу о отсутствии в мк IO, угумс... Так что как видишь, в моем случае я могу выбирать - хочу ли я вон то с такой ценой, или нафиг. И это _мое_ решение, из _моих_ соображений, а не некая универсальная истина. И я сишку использую как раз чтобы эти возможности у меня были. Безопасные песочницы - для детишек. А мне можно и не совсем безопасные вещи, если я понимаю соотношения. > представляешь — даже ужасный GC использую. удобно. а иногда не использую. а
> иногда и использую, и не использую. Я рад за тебя и все такое. Не обязывает меня быть фанатом этого всего. > хвалёный gcc не умеет в symbolic analysis, и не может доказать, что
> в цикле проверка не нужна, потому что out-of-bounds никогда не будет? ну ой. Вообще, с LTO он это довольно неплохо умеет. Но даже так - это все срабатывает далеко не на 100% кода, ибо довольно часто все зависит от заранее неизвестных входных данных. Как ты там собрался "доказывать" что я получу с ADC, радиолинка и проч? Там что угодно может быть. И в этом случае - нравится, не нравится, рантайм проверка будет. Это _я_ могу попробовать доказать, а потом проверить сильно отдельно поля пакета ДО того как начать тяжелый loop на их основе, заранее зная как задуман парсинг, и какие значения поля валидны а какие уже нет, но вот компилеру это все - так сразу не видно. >> это заведомое и сильное усложнение жизни себе.
> я не всегда ищу самый лёгкий путь. иногда предпочитаю *правильный*. На самом деле это даже неплохо, но я видел много случаев когда погоня за правильностью отлично...гробила проекты в хлам. В результате - мир уходил вперед, место занимали "менее правильные" проекты, а "правильная" заброшка догнивала на задворках цивилизации. Я в курсе этого паттерна и неизбежно учитываю его, очень критично оценивая соотношения. Классический пример? Ну, вот, btrfs vs всякие шишкины. Эстеты, конечно, покажут правильную замену? Ах, нет? Значит, эстеты будут - optimized out. Будущее случится без них, со всеми неидеальностями. Потому что у тех вообще - "failure to deliver". > я очень много чего сказал, когда на это наткнулся. впрочем, из приличных
> слов там были только паузы. хотя и те отдавали матерком. Ну я даже согласен что сие не есть приятный подарок. Но он до энной степери понимаемый. И я все же вижу определенные двойные стандарты когда некто парится bounds check, но silent truncate его не парит почему-то, хотя точно так же может вести к багу в поведении софта, вплоть до вулнов. > повторю: почему оно не реагирует на `+`? Возможно потому что у дидов код состоит из такого чуть менее чем полностью? Да, эти нехорошию господа любили везде "int" дежурно пихать. И так то даже i++ в общем случае - UB, если не удалось доказать границы диапазона i. Но если варнинг будет на почти весь код - толку с него будет мало. Если ты хотел мое мнение - я бы ввинтил варнинги в обеих случаях, ибо не лю раздолбайский стиль дидов и к чему оно ведет. > в отличие от `snprintf()` — плюс с целыми знаковыми может привести к UB. Урезание строки неожиданным для программера образом тоже может сломать логику программы. На лично мой вкус я б и то и другое рубал, но "диды" взвоют, и слишком много спама в их коде будет. Мое мнение о коде из "int" мы тактично оставим при себе. Ну так, заткнув пару overflow и negative index'ов при энных значениях воон там. Но в core это кот дида, запилившего рида соломона достаточно легко чтобы это в мк лезло. И как ты понял, потерять ТАМ 30% скорости я могу и напрячься в ряде случаев, особенно в пакости типа avr. (Удачи тебе в програминге бэка этому странному уродцу, кст.) Я там и при рефакторе то чуть не спятил, berlekamp-massey не для средних умов, трек worst case значений переменных для валидации не совсем просто было. Однако как показала практика я все ж могу немного въехать и в такое и даже например своим ходом запилить генерацию "странных таблиц" получив +2 варианта, с другими tradeoff по [скорость, жор RAM, жор Flash]. > потому что ключи ищут не там, где потеряли, а там, где светло? Такое тоже бывает. Но положа руку на сердце, идея писать бэк кодогенерации для допустим AVR ничего кроме благоговейного ужаса у меня не вызывает. Древние уже сделали почти чудо как-то натянув сову относительно нормального си на ЭТО. В мои планы занятие такиими извратами не входит, хорошо что я могу отдать результату мучений древних свой код и получить бинарник. > отлично. я написал `(void)snprintf(…)`. почему оно не заткнулось? почему такое вообще
> попало в официальный релиз? гоцэцэ совсем перестали тестировать? ну, я бы не удивился. А я знаю? Вариантов может быть более 9000. Ты даже ссыль на это не накинул. > см. выше про `+`. Тогда и про (int) i++ сразу, чтоб 2 раза не вставать. Вопрос, на каком % кода это орать будет? Не праздный вопрос дял варнинга, да? > вы там делать будете. но что-нибудь такое, чтобы компилятор ваш `if`
> не убрал, а то ворнинг обратно выскочит. короче, займитесь ублажением компилятора,
> нам плевать на ваши проблемы. Это в принципе обычно для статических анализеров и компилеров, они могут и перестраховываться по состоянию на сейчас. И в целом я поддерживаю это направление движения. Я бы и для "operator +" для int ныл бы. Впрочем там и "operator -" может испытывать траблы. Т.е. int foo(int a, int b) { return (a - b); } тоже может быть UB. Представь себе что a близко к отрицателному минимуму, и b тоже. А, в диапазон не лезет, будет wrap, который для signed - ub? И в результате что? Орать на почти все сишные программы? Ну, воткни себе в компилер "warning: ingeger math in C prone to UB!", можно безусловно, не сильно промажет :) > у меня довольно много таких вызовов. и я не вижу никакой необходимости
> делать для них дурацкий бесполезный врапер. более того: если я хорошо
> врапер аннотирую — ворнинг вылезет уже на нём. а если не
> аннотирую — потеряю, например, проверки форматной строки. спасибо, очень удобно,
> всю жизнь о такой фиче мечтал. А у тебя были какие-то идеи лучше как этот класс багов ловить и при этом не жестить? Хотя с void в принципе не так уж плохо придумано. > см. выше про `+`. Если что оно и с `-` возможно. И root cause как таковой это ub при signed математике. Хотя некоторые програмеры и wrap от unsigned могут прошляпить. Если на ВСЮ целочисленую математику проверок в принудиловку навешать - это уже не будет си. А не в принудиловку - так я ж сказал что ubsan, даже минимальный, с bad opcode, ловит такое влет. >> Реальности изменились, tradeoffs - тоже. И теперь стандарты кодинга стали жестче.
> а программирования — остались какими были. А вот это уже решать не тебе, и не мне, увы и ах. Оно таки будет двигаться более менее глобальным консенсусом в ту или иную сторону. И да, математику с int тоже заткнули бы - но в существующем статус кво это будет орать на каждую первую программу по сути, и это полностью рюхается только в рантайме, что не халявно для алгоритмики. А варнинг на вообще каждую прогу - малополезен. >> Раздолбаить стало непочетно.
> пчёлы против мёда. В каком-то роде да. Я так понимаю что где можно подрезать крылья - чтобы раздолбавить стало неудобно, подрезают. А где это ведет к ору на ВСЕ программы - ну и смысл? >> Расчистка барахла по площадям.
> ой, а кто же там намусорил-то? Диды с их чудным кодингом. См. выше мое мнение про качество их кода. И таки как видишь я в курсе грабель сей. И стандарты читал. Поэтому и лю минимум C99 и другие типы. Но - увы - это не распостраняется на препроцессор, а есть еще всякие странные зверушки типа enum, которые вообще хрен знает какого типа. И это вообще-то вопрос не к GCC - а к стандартизаторам. > ну да. судя по твоему описанию твоих практик — я бы, скорее
> всего, твои патчи не принял. так что ты, в принципе, прав. ;-) Бы не считается. Я дам 99% что обнаружу характерный прожектменеджмент задолго до того как речь пойдет о чем-то таком, и просто не буду юзать такой софт. А коли так то и причин слать патчи нет. Заодно посмотрим что стайка высокомерных снобов от академа может своим ходом и чего стоят их блабла, и куда этот вектор приведет. Все виденные варианты мне не нравились достаточно для того чтобы желать для моей тушки каких-то иных версий будущего, пример вон тех был достаточно убедителен. >> Если полпланеты землю копытом роет, вероятно
> …проект, наконец, дозрел. Лол :) > потому что большинство людей или молча жрут то, что им скармливают авторы
> гоцэцэ (ты тут уже который пост мне доказываешь, что надо жрать
> и благодарить за тёплую шапку), Хуже для тебя и дидов - я поддерживаю этот курс, из-за моих интересов к управляющим системам. И к int я б тоже это применил - как ты и вещал - но catch в том что варнинг на каждую первую программу все же - бесполезен. И вот тут режим прагматика побеждает - в ТАКОМ виде warning расово верно, но на практике, увы, не ценно. Если варнинги будут на каждую 1ю программу, на них все просто забьют. И вот тут надо начинать - имхо - с ISO и его стандартов с UB. Но между нами даже хрустики проверяют математику на врап только в debug билдах. Т.е. как сишка с ubsan примерно. В release - слишком дорогое удовольствие, увы и ах. Не, получить пасквиль голимый из си я не хочу. > кстати — обычно совпадает с множеством людей, которые действительно понимают в
> том числе и внутреннюю механику, и не боятся компиляторов, кодогенов и асмов. Во первых я понимаю асм. Во вторых удачи тебе с кодогене под какой там AVR, в третьих - попробуй сделать современный GCC или шланг с LTO по скорости и размеру кода. А простой кодоген, увы, не сможет в многие оптимзации и код будет хуже. >> Багов бояться - софт не девелопать.
> продолжение квинтэссэнции современного «девелопинга». Увы, мир становится сложнее - и не идеален - поэтому приходится придумывать энные вещи балансирующие трудносочетаемые желания. Да, я совсем не хочу пасквиль галимый с неотключаемыми рантайм проверками математики как системный ЯП.
- Допустим, Кернигана и Ритчи оставили в покое А в какое плодотворное русло напра, Аноним (87), 17:09 , 25-Ноя-24 (290)
- Скрыто модератором, Аноним (-), 18:43 , 25-Ноя-24 (299) [---]
- Похоже таки отпустили на пенсию Это да Но это - другое А для Си - для меня , _ (??), 06:15 , 28-Ноя-24 (352)
> Допустим, Кернигана и Ритчи оставили в покое.Похоже таки отпустили на пенсию :)
> А в какое плодотворное русло направлять усилия, совершенно новые языки пилить? Так эти усилия и так полны плодами. Это да :) Но это - другое. А для Си - для меня самая большая хотелка - сделайте в нём модули (да хоть как в Go) и уберите нах инклюды ... а может даже и весь препроц! 8-о ... хотя наверное это уже ыкстрмизьмЪ :)
- strdup очень безопасная функция, особенно когда принимает неалоцированную строку, Я (??), 22:27 , 26-Ноя-24 (339)
strdup очень безопасная функция, особенно когда принимает неалоцированную строку, питонисты добились её утверждения в стандартные
- 35 лет допиливали язык Вот это я понимаю поддержка , Соль земли (?), 09:52 , 27-Ноя-24 (347)
35 лет допиливали язык. Вот это я понимаю поддержка!
- Вот, реально задалбывает в плюсах ну ввели вы новую погребень - ДАЙТЕ ЛЮДЯМ ЭТО, InuYasha (??), 20:49 , 27-Ноя-24 (348)
Вот, реально задалбывает в плюсах: ну ввели вы новую погребень - ДАЙТЕ ЛЮДЯМ ЭТО ПРОВЕРИТЬ!> добавление константы nullptr #if !defined(nullptr) - хрен вам! сосите лапу.
#define nullptr (void *)0x0 // условно так уже достало писать слой портабельности на все компиляторы с 90ых годов!..
- 20 лет просил об этой хреноте и всё равно сделали что-то ж не то что хотелось , InuYasha (??), 20:55 , 27-Ноя-24 (349) +1
> В стандарт включены операторы typeof и typeof_unqual, 20 лет просил об этой хреноте и всё равно сделали что-то ж...не то что хотелось. А всего-то надо было typeof(a) == typeof(b)...
|
Свернуть нити
Пометить прочитанным
Создать тему
