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

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

Сообщения

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

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

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

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

	132. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (132), 24-Ноя-24, 10:17
	Поверьте налепив сверху на ассемблер макросов можно с легкостью слабать любой сайт ))
	Ответить | Правка | Наверх | Cообщить модератору

	174. "GCC 15 будет использовать стандарт C23 по умолчанию"	+3 +/–
	Сообщение от Аноним (174), 24-Ноя-24, 13:55
	зачем это декаденство? любой сайт можно с легкостью спаять
	Ответить | Правка | Наверх | Cообщить модератору

	184. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (184), 24-Ноя-24, 15:06
	Ассемблер это и есть набор макросов над набором инструкций процессора. А вот если бы кто-то придумал способ превращать более абстрактные, высокоуровневые конструкции в ассемблер для любого набора инструкций...
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

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

	249. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (249), 25-Ноя-24, 09:27
	Так это делают компиляторы с языков ВУ.
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

	327. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 26-Ноя-24, 14:55
	> Поверьте налепив сверху на ассемблер макросов можно с легкостью слабать любой сайт )) На сях микросервис может как на go быть, если правильную либу взять. Т.е. полстранички текста. Скажем см https://lwan.ws - hello world менее чем полстраницы может быть. И это на сях. После чего он еще и в топе любого тематичного бенча отвиснет. А покажете на асме такое? :)
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

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

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

	201. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от ryoken (ok), 24-Ноя-24, 16:29
	...пересмотреть что ли...
	Ответить | Правка | Наверх | Cообщить модератору

	146. "GCC 15 будет использовать стандарт C23 по умолчанию"	–3 +/–
	Сообщение от Тот_Самый_Анонимус_ (?), 24-Ноя-24, 11:46
	Ну, кстати, 0b, 0B и %b были вполне логичны изначально. А вот true и false излишни. Меня радовало их отсутствие после мерзского паскаля.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	147. "GCC 15 будет использовать стандарт C23 по умолчанию"	+4 +/–
	Сообщение от нах. (?), 24-Ноя-24, 11:49
	не, ну как только в процессорах появятся "true" и "false", а не jz, так сразу пусть и приходят. А пока да - совершенно вредоносная фигня, скрывающая суть операций. Тем более в языке с автоматическим приведением типов.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 15:22
	> не, ну как только в процессорах появятся "true" и "false", а не > jz, так сразу пусть и приходят. > А пока да - совершенно вредоносная фигня, скрывающая суть операций. Тем более > в языке с автоматическим приведением типов. Наличие или отсутствие "jz" в конкретном процессоре - вообще не гарантировано. А если ты хотел на ассемблере шпрехать - вот на нем и шпрехай. Прибитый к 1 архитектуре сишка нафиг не упал.
	Ответить | Правка | Наверх | Cообщить модератору

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

	206. "GCC 15 будет использовать стандарт C23 по умолчанию"	–2 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:39
	>> Наличие или отсутствие "jz" в конкретном процессоре - вообще не гарантировано. > лолшта? Процессор без условного перехода - еще не изобрели. Как именно реализованы у конкретного проца условные переходы и какие там условия - это implementation defined и это как раз то от чего мы в си хотим абстрагироваться. Не хотели - юзали бы макроассемблеры, мля. > А когда изобретут, в нем вряд ли будут работать процедурные языки вообще. Ну какие-то условные операнды конечно быть должны, но так для понимания на тебе SUBLEQ. Такой вот набор команд. Не совсем jz, да? Конечно это мастеркласс брейнфаку как надо было но это тюринг полный набор команд :)
	Ответить | Правка | Наверх | Cообщить модератору

	236. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от нах. (?), 24-Ноя-24, 18:50
	> Как именно реализованы у конкретного проца условные переходы и какие там условия - это > implementation defined но проца с истиными true/false ты конечно же не покажешь. Проца без jz полагаю тоже. > и это как раз то от чего мы в си хотим абстрагироваться кто эти вы и в одной ли с вами они сейчас комнате? > Не хотели - юзали бы макроассемблеры, мля. У pdp-11 был прекрасный макроассемблер. Но авторы Си хотели немного сэкономить себе долбежку по клавиатуре (а вовсе не "абстрагироваться" - для феноменально т-пых повторяю - вот a[i++] - это никакая не абстракция, это особенность архитектуры именно этой машины, и может быть еще у vax была такая же. И ничего, все пользуемся.) > но это тюринг полный набор команд Но нигде не используется и не будет. Поэтому по прежнему придется помнить что все что нельзя привести к integer 0 - является true.
	Ответить | Правка | Наверх | Cообщить модератору

	244. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 24-Ноя-24, 21:07
	> проца с истиными true/false А я думал ты шутишь так. В процессорах нет типов, там и nullptr нет и enum, много чего нет. И мало что есть! Есть -0. Он у тебя truthy или falsy? Если без вредоносной фигни.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от нах. (?), 25-Ноя-24, 10:15
	> Есть -0. Он у тебя truthy или falsy? Если без вредоносной Он у меня вообще непригоден для условных переходов, его только сравнить с другим нулем можно. У меня нет процессоров с минуснулем который можно использовать как условие. Возможно они когда-то были во времена ламповых компьютеров с гарвардской архитектурой, но это неточно. У тех может и отдельная лампа для true была. Но си для них все равно не скомпилируется, 4k памяти не хватит. nullptr там вполне себе есть, иногда по нему даже можно что-то записать. Это просто соглашение, что мы ноль в этом месте считаем признаком что что-то пошло не так. И да, это тоже удобное наследие pdp (тоже экономит одну команду на каждой проверке). Писали б юникс для микроконтроллеров - наверное выбрали бы другое значение, поскольку там очень даже нужны иногда записи в 0 смещение и вот хз как это сделать без костылей. enum просто синтаксический сахар для константы, любой макроассемблер позволит тебе создать свой enum. И да, в процессорах есть типы, внезапно. Причем автоприведения нет. И просто так положить твой -0 в целочисленный регистр нельзя вообще никак. А где-то тебя ждет еще и фиаско при попытке прочитать туда символ с неверным смещением.
	Ответить | Правка | Наверх | Cообщить модератору

	296. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 25-Ноя-24, 18:17
	> nullptr там вполне себе есть В процессорах есть типы, среди которых nullptr_t, ну и ну. > enum просто синтаксический сахар для константы, любой макроассемблер А стандарт говорит о каких-то enumerated types. > Он у меня вообще непригоден для условных переходов, его только сравнить с другим нулем можно. Как и всё остальное. Но почему-то к 0 и 1 в сях у тебя претензий не было, а к false и true - есть. И где в сях Zero Flag?.. > И просто так положить твой -0 в целочисленный регистр нельзя вообще никак "Просто так вообще никак" - это как? Берёшь из памяти и кладёшь.
	Ответить | Правка | Наверх | Cообщить модератору

	298. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 18:41
	>> nullptr там вполне себе есть > В процессорах есть типы, среди которых nullptr_t, ну и ну. У cortex-M в каком-то роде есть - попытка дереференснуть адрес 0 в этом проце дает немедленный HARD FAULT. Не любит фирма ARM null pointer dereference :) > А стандарт говорит о каких-то enumerated types. Да это пох, эникеев бox, живет в мире где C89 во все поля. Хотя уже даже и майнлайн на C11 ушел. > у тебя претензий не было, а к false и true - > есть. И где в сях Zero Flag?.. >> И просто так положить твой -0 в целочисленный регистр нельзя вообще никак > "Просто так вообще никак" - это как? Берёшь из памяти и кладёшь. В принципе можно попробовать задекларить переменную как register, но компилер в праве на это забить.
	Ответить | Правка | Наверх | Cообщить модератору

	354. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (354), 28-Ноя-24, 18:38
	Фиг с ними, с условными переходами. Сколько бит занимает true или false? 8 или меньше? Один? Значение получается сдвигом или без лишних инструкций? Может, есть процессоры, где можно адресовать меньше байта? А с литеральным нулём и единицей всё понятно.
	Ответить | Правка | К родителю #296 | Наверх | Cообщить модератору

	357. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (357), 28-Ноя-24, 19:03
	> сдвигом или без лишних инструкций? Может, есть процессоры, где можно адресовать > меньше байта? Легко. См например ARM - и какой нибудь BFI (Bit Field Insert). Хоть бит, хоть битовое поле сразу. Да, так можно было. А в микроконтроллерах они пошли дальще и сделали bitbanding. Это когда телепание u32 по энному адресу атомарно телепает бит в соответствующем этому региону месте. И так можно оформить изменение бита без явного RMW в софте.
	Ответить | Правка | Наверх | Cообщить модератору

	367. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (367), 29-Ноя-24, 18:50
	> В процессорах есть типы И с этого начинается самое первое знакомство с процессором: байт, слово, двойное слово и т.д. Это - типы данных, с которыми работает процессор. >> И просто так положить твой -0 в целочисленный регистр нельзя вообще никак >"Просто так вообще никак" - это как? Берёшь из памяти и кладёшь. Ну вот, я кладу в восьмибитный регистр 0 - 00000000 Покажи, как ты запишешь туда -0. > А стандарт говорит о каких-то enumerated types. Стандарт на процессор?!
	Ответить | Правка | К родителю #296 | Наверх | Cообщить модератору

	369. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 30-Ноя-24, 05:01
	> Ну вот, я кладу в восьмибитный регистр 0 - 00000000 > Покажи, как ты запишешь туда -0. а ещё вот так можно, например: pushd 0x80000000 movss xmm0, [esp] add esp, 4 ой, в первом элементе xmm0 теперь `-0`. который отличается от `+0`, и это таки можно проверить при желании. внимательно слушаю рассказ о том, что SSE — не часть процессора.
	Ответить | Правка | Наверх | Cообщить модератору

	355. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 28-Ноя-24, 18:44
	> У меня нет процессоров с минуснулем который можно > использовать как условие. то есть, на твоих процессорах отсутствует реализация IEEE 754? хреново, бро.
	Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

	266. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Совершенно другой аноним (?), 25-Ноя-24, 12:32
	> Проца без jz полагаю тоже. RISC V. Там совмещённые команды (BEQ/BNE/BLT/BGE, см. https://habr.com/ru/articles/558706/), без проверки флажков, сразу и сравнивает регистры и, если условие истинно, переходят по указанному смещению.
	Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

	297. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 18:34
	> но проца с истиными true/false ты конечно же не покажешь. На минуточку вся цифровая логика это 1 и 0, true и false. И что такое "5" если я с лапкой GPIO работаю например? Там либо 1, либо 0. > Проца без jz полагаю тоже. Ну покажи вот именно jz в RISCV? Да и у ARM могут быть свои идеи на этот счет. А когда кто-то на именно си прогает - он вообще не очень хотел знать именно такие детали. Для желающих копаться на таком уровне - есть асм. > кто эти вы и в одной ли с вами они сейчас комнате? Это например целый линух, где 1 и тот же драйвер прекрасно билдится под x86, ARM, MIPS и RISCV. А загонялся бы драйвер "jz" - и переписывали бы мы эти дрова на манер колибри-ос. А оно кому-то надо? >> Не хотели - юзали бы макроассемблеры, мля. > У pdp-11 был прекрасный макроассемблер. Но авторы Си хотели немного сэкономить себе > долбежку по клавиатуре (а вовсе не "абстрагироваться" - Да какая разница что хотели авторы C в лохматых годах? На K&R уже кмк вообще никто не пишет. Настолько что его уже и выкинули, вот, даже. Более того, можешь поискать коменты авторов си на тему UB. Они прямо сказали мол сие не было нашей частью плана, это все - комитет, в угоду упрощения реализаций и оптимизаций. Вот так детище начинает жить своей жизнью, забыв авторов спросить. > повторяю - вот a[i++] - это никакая не абстракция, это особенность > архитектуры именно этой машины, и может быть еще у vax была > такая же. И ничего, все пользуемся.) Со временем таких особенностей отросло у почти всех современных процов. А как раз чтоб экономить на размере потока команд и улучшать скорость операций. >> но это тюринг полный набор команд > Но нигде не используется и не будет. Это вопрос номер два. > Поэтому по прежнему придется помнить что все что нельзя привести к integer 0 - является true. В сях немного иные рулеся булеанов. Все назначения булеанов обрубаются до 1. Все что не 0 является true в булеановской логике. В целом - это некий набор антиграбель. Чтобы как раз ничего не "помнить" а уповать на автоматику, и писать if (var) { do; something; }. Не особо грея мозг как оно там внутри но получив well defined behavior. Как бонус, в ряде систем команд типа ARM, кодирование маленьких констант типа 0 и 1 - эффективнее чем весь огроменный int32 передать.
	Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

	356. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 28-Ноя-24, 18:49
	> Все что не 0 является true в булеановской логике. В целом > - это некий набор антиграбель. эвона как. отстутствие нормального булевого типа — это антиграбли. ну подумаешь, написал `(a & b)` а не `(a && b)` — компилятор и не квакнул. в нормальном языке побитовые операции (и вообще арифметика) к булам неприменимы. и наоборот: булевы операции неприменимы к другим типам. но это, конечно, грабли. антиграбли — это молча слопать любую ерунду, потому что вместо нормальной системы типов завезли фэйк.
	Ответить | Правка | Наверх | Cообщить модератору

	358. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (357), 28-Ноя-24, 19:06
	> эвона как. отстутствие нормального булевого типа — это антиграбли. ну подумаешь, > написал `(a & b)` а не `(a && b)` — компилятор и не квакнул. Думаю что статический анализатор это таки отловит. > в нормальном языке побитовые операции (и вообще арифметика) к булам неприменимы. и > наоборот: булевы операции неприменимы к другим типам. но это, конечно, грабли. > антиграбли — это молча слопать любую ерунду, потому что вместо нормальной > системы типов завезли фэйк. Это все прекрасно - кроме того что эти языки не с нами там где все вон то реально надо было. И о чем мы тут вещаем? А так да, сишка несколько педальный, зато эта педальность при случае позволяет все же сделать вон то - если очень надо. А не упереться рогом жестко в ограничения.
	Ответить | Правка | Наверх | Cообщить модератору

	360. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 28-Ноя-24, 19:20
	>> эвона как. отстутствие нормального булевого типа — это антиграбли. ну подумаешь, >> написал `(a & b)` а не `(a && b)` — компилятор и не квакнул. > Думаю что статический анализатор это таки отловит. антиграбли, которые надо усердно ловить дополнительной тулзовиной. отличные антиграбли, всегда о таких мечтал. дайте два набора! ведь компилятор — он не для того, чтобы ошибки типизации отлавливать. > Это все прекрасно - кроме того что эти языки не с нами > там где все вон то реально надо было. ну кто ж вам виноват, что вы в своём пузыре ничего кроме сишечки не имеете? компилятор модулы не то чтобы шибко моложе компиляторов сишечки, например. но недоучки и тогда не понимали, зачем нужна строгая типизация — и сейчас не понимают. > А так да, сишка несколько педальный, зато эта > педальность при случае позволяет все же сделать вон то - если > очень надо. А не упереться рогом жестко в ограничения. удивительное дело: на модуле оси были. на обероне оси были. и булевский тип там нормальный. наверное, эти глупые языки не позволяли сделать то, что надо — ни с железом общаться, ни битовые операции, ни… короче, ничего не позволяли, оськи божьим промыслом сделались.
	Ответить | Правка | Наверх | Cообщить модератору

	370. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (370), 30-Ноя-24, 05:23
	> антиграбли, которые надо усердно ловить дополнительной тулзовиной. отличные антиграбли, Да, у комитета полудурков есть привычка - сделать 90% фичи и затем почему-то феерично облажаться с остальными 10%. Они вообще хотели bool совсем выпилить, в пользу bit exact integers в этом релизе сначала. С enum, они, видишь ли тоже даже при typedef в это и скажем параметре функции с таким типом - не ловят левак на входе отсутствующий в том enum, хотя все аннотации намерений - в коде есть. > всегда о таких мечтал. дайте два набора! ведь компилятор — он > не для того, чтобы ошибки типизации отлавливать. Ну вот именно bool - далеко не самый проблемный топик в сяъ. Меня больше int неопределенного размера бесит, и integer promotion деланый - кем то под веществами. А там еще препроцессор сбоку есть и в нем тоже математика и условия возможны. И таки по моему сейчас варнинг на if (a & b) чуть ле не тулчейны уже умеют фигарить, ибо подозрительная конструкция. А уж что-то типа cppckeck в bug hunting mode - засветит такое на раз. Да, это больше шума и ложняков, exploratory режим для изучения баг это или не баг. >> Это все прекрасно - кроме того что эти языки не с нами >> там где все вон то реально надо было. > сишечки, например. но недоучки и тогда не понимали, зачем нужна строгая > типизация — и сейчас не понимают. Да сам пиши на своих модулах и оберонах, а потом по осени посчитаем цыплят, на тему кто чего смог, угу. Чего ты ко мне с этим докопался? Как мне еще понятнее объяснить что мое сердце принадлежит - curly bracket? И ЧСВ об меня пытаться чесать - а смысл? Это еще никому никогда ничего хорошего не дало. Зачем даже пытаться в это? Не понимаю. > удивительное дело: на модуле оси были. на обероне оси были. и булевский > тип там нормальный. В этом месте анекдот про неуловимого джо вспоминается. Наверное какую-то ось даже на брейнфаке можно накорябать. Но вот длинного списка желаюших это делать я что-то не вижу. Реалистично мне можно втулить "как си но лучше". Не, без curly bracket это не "как си" от слова вообще. > наверное, эти глупые языки не позволяли сделать то, > что надо — ни с железом общаться, ни битовые операции, ни… > короче, ничего не позволяли, оськи божьим промыслом сделались. Удачи тебе с этими ос и божьими промыслами. Мне это в таком виде - с тем синтаксисом - нахрен не вперлось ни с правильным бульоном, ни с неправильным. Да, у меня есть некие предпочтения в синтаксисе. И программировать в виде когда мне синтаксис отвратителен - не вариант, и ты отлично в курсе.
	Ответить | Правка | Наверх | Cообщить модератору

	371. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 30-Ноя-24, 05:38
	> Да сам пиши на своих модулах и оберонах а я и пишу. как раз на своих, гыг. > Чего ты ко мне с этим докопался? есть у меня глупая привычка после заявления, что где-то сделано плохо — приводить пример, где сделано хорошо. извини, быдло я, что поделать. > И ЧСВ об меня пытаться чесать - а смысл? в данном случае — обо всех сишников. потому что это местами забавно. >> удивительное дело: на модуле оси были. на обероне оси были. и булевский >> тип там нормальный. > В этом месте анекдот про неуловимого джо вспоминается. «я не видел — значит, не существует и не нужно!» ну, не видел ты AOS на STM — бывает. можешь рассказать мне, что её не существует, и в промышленности не применяется. > Удачи тебе с этими ос спасибо, но удача мне не нужна: у меня и без применения удачи всё работает.
	Ответить | Правка | К родителю #370 | Наверх | Cообщить модератору

	379. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 04-Дек-24, 09:27
	>> Да сам пиши на своих модулах и оберонах > а я и пишу. как раз на своих, гыг. Ну мы по осени и посчитаем - у кого какие списки проектов будут. Со своей стороны я ставлю на то что мой прагматичный настрой позволит сделать мне больше вещей которые я считал интересными для себя. >> Чего ты ко мне с этим докопался? > есть у меня глупая привычка после заявления, что где-то сделано плохо — > приводить пример, где сделано хорошо. извини, быдло я, что поделать. В конкретно моем случае - меня, увы, бесит паскалеобразный синтаксис. И общий стиль потуг строить кого-то в обязаловку. Я считаю что в системном тулсе такие вещи должны быть под контролем. Хотя разумный баланс ближе скорее к тому что хрустики сделали с unsafe. Т.е. видишь - я и сам могу показать тул где ряд вещей сделаны лучше по моему мнению. А то что это здорово другой тул - упс. >> И ЧСВ об меня пытаться чесать - а смысл? > в данном случае — обо всех сишников. потому что это местами забавно. При этом кучу софта от этих сишников юзал, а в итоге - дриснул сверху на их головы. А без них ты бы даже на опеннет пискнуть не смог, имхо. И ты потом удивляешься что за такой менталитет другие вас не лю, и обходят таких и их проекты за версту? >> В этом месте анекдот про неуловимого джо вспоминается. > «я не видел — значит, не существует и не нужно!» ну, не > видел ты AOS на STM — бывает. можешь рассказать мне, что > её не существует, и в промышленности не применяется. На этом глобусе есть много чего. И применяется - тоже. Для лично меня -  STM32 и т.п. это last line of defence, максимально простые и дубовые штуки, с минимумом места для лажи, аналоговые фронтэнды, GPIO/IIO и жесткое реальное время. Это как правило вообще - "non OS". Потому что так я могу потрогать микросекунду руками, шустро мониторить энный процесс и проч. Например мне нравится "software controlled DC-DC", когда софт рулит преобразованием напряжения. В смлу простоты начинки и следования вооон тем рекомендациям - мне и на си такое нормуль. Тем более что при нужде я подстраховываюсь хардварными защитами, да и не умрет все же никто. Но выгореть что-нибудь при лаже софта - могет. >> Удачи тебе с этими ос > спасибо, но удача мне не нужна: у меня и без применения удачи всё работает. Ну зашибись. У меня, в общем то, в конечном итоге - тоже.
	Ответить | Правка | К родителю #371 | Наверх | Cообщить модератору

	381. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 04-Дек-24, 10:01
	>>> Да сам пиши на своих модулах и оберонах >> а я и пишу. как раз на своих, гыг. > Ну мы по осени и посчитаем - у кого какие списки проектов > будут. ты до сих пор вот этим вот меряешься? O_O ну, тогда я могу свой дурацкий критерий выкатить: у тебя нет своего компилятора. ты проиграл. > Со своей стороны я ставлю на то что мой прагматичный > настрой позволит сделать мне больше вещей которые я считал интересными для > себя. думал о том, что мне *интересно* писать, например, компиляторы? ;-) как (и зачем) ты вообще собрался сравнивать зелёное и снусмумрика? > В конкретно моем случае - меня, увы, бесит паскалеобразный синтаксис. не верю я в это. подобные болезни обычно проходят после первых пяти, ну десяти максимум лет — когда ты уже достаточно опытен, чтобы писать именно программы. на этом месте начинает волновать семантика, а синтаксис… ты его просто не замечаешь. темнишь ты что-то, ой, темнишь. > И общий стиль потуг строить кого-то в обязаловку. проклятый оберон! требует писать `IF cond THEN .. END`! не то что сишечка, она-то не требует, например, скобочки после `if` ставить! > Я считаю что в системном тулсе такие вещи должны быть под контролем. какие «такие»? ты вообще оберон-то знаешь? или даже рабинович не напевал? вот скажи: ты видел меня когда-нибудь рассуждающем о том, что в хаскеле неправильно в смысле языка? и не увидишь. потому что я не имею привычки с умным видом рассказывать что неправильно в том, о чём я имею в лучшем случае самое поверхностное представление. (я считаю непрактичной саму идею, но это другая сказка. ;-) ты уже в который раз сообщаешь мне ломающие новости: оказывается, в обероне-то никак, совсем никак невозможно то, без чего невозможно на нём написать ни ось, ни рантайм. однако ж и то, и другое написаны. может ты хотя бы для разнообразия сначала изучишь то, о чём говоришь? или просто прямо скажешь: «не желаю ничего знать!» потому что твои обоснования отчего-то очень напоминают «да зелен этот виноград!» > Т.е. видишь - я и сам могу показать тул где ряд вещей > сделаны лучше по моему мнению. А то что это здорово другой > тул - упс. лучше *чего*? ты не можешь показать ничего лучше оберона просто потому, что оберона ты не знаешь. так что и сравнивать не можешь. > При этом кучу софта от этих сишников юзал, а в итоге - > дриснул сверху на их головы. так я даже на gw-basic софт использовал. это причина считать gw-basic хорошим языком, а пишущих на нём богами, про которых нельзя ничего говорить? странный закидон. аргументы кончились, что ли? > А без них ты бы даже на опеннет пискнуть не смог, имхо. да вообще-то могу: браузера в AOS на это хватает. просто мне сейчас не надо писать в AOS — вот я и не там. как-нибудь сделаю клиента к опеннету на BlackBox: в принципе, давно пора. а на чём там сам опеннет работает — мне неважно: хоть на спичках. то, что кто-то выбрал какую-то технологию, никак не обязывает меня эту технологию считать хорошей. > И ты потом удивляешься что > за такой менталитет другие вас не лю, и обходят таких и > их проекты за версту? я не удивляюсь, я очень этим фактом доволен. меньше всего мне в проектах нужны адепты сишечки, которые уверены, что сишечку надо уважать только за то, что на ней разговаривал пушкин. кстати, интересное наблюдение: адепты сишечки обычно демонстрируют агрессивное незнание оберона. оберонщики же сишечку в подавляющем большинстве таки знают, и весьма хорошо. получается, что первые выбирали язык «потому что как все», а вторые — «потому что мне удобно». ой. > На этом глобусе есть много чего. И применяется - тоже. интересный факт: ты НИ РАЗУ не признал, что неправ. каждый раз, когда я тебе говорю про конкретные практические применения вещей «от академиков» — ты начинаешь туманно рассуждать, что на свете есть многое, друг горацио, космические корабли бороздят просторы большого театра. а когда достаточно покрутил кильку у причала — опять возвращаешься к «академики ничего практического не зделоли!»
	Ответить | Правка | К родителю #379 | Наверх | Cообщить модератору

	181. "GCC 15 будет использовать стандарт C23 по умолчанию"	–2 +/–
	Сообщение от Аноним (181), 24-Ноя-24, 14:52
	> Ну, кстати, 0b, 0B и %b были вполне логичны изначально. ЧСХ я ими и пользовался уже лет 10. Просто как GNU Extension. Все равно вон та фирмварь чем-то кроме GCC - не соберется. Ибо в стандартном си даже положить объект в конкретную секцию нельзя. > А вот true и false излишни. Меня радовало их отсутствие после мерзского паскаля. Особенно радовадо в каком-нибудь uint8_t var = 0xFF + 1; ... if (var) else // А мы точно собирались - сюда?!
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	167. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (167), 24-Ноя-24, 13:15
	Микроконтроллерщики уже на C++
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	187. Скрыто модератором	+2 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 15:24
	> Микроконтроллерщики уже на C++ Отучаемся говорить за всех.
	Ответить | Правка | Наверх | Cообщить модератору

	250. Скрыто модератором	+/–
	Сообщение от Аноним (249), 25-Ноя-24, 09:35
	А мы ещё и не начинали.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (237), 24-Ноя-24, 18:51
	> Добавлена поддержка префиксов "0b" и "0B" для указания целых значений в двоичной форме Пятьдесят джва года ждал! Как в DOS в своё время не хватало, всякие железки в порты тыкать.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	257. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от нах. (?), 25-Ноя-24, 11:47
	>> Добавлена поддержка префиксов "0b" и "0B" для указания целых значений в двоичной форме > Пятьдесят джва года ждал! > Как в DOS в своё время не хватало, всякие железки в порты > тыкать. так и запишем - восьмеричная система счисления тебе не далась. (а начинал бы не с доса а с нормальных систем на нормальных компьютерах - знал бы, что двоичная форма нахрен не нужна)
	Ответить | Правка | Наверх | Cообщить модератору

	262. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (237), 25-Ноя-24, 12:14
	Так и запишем — ты совершенно не понял, о чём речь.
	Ответить | Правка | Наверх | Cообщить модератору

	264. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (264), 25-Ноя-24, 12:19
	В DOS и x86 была принята шестнадцатеричная.
	Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

	301. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 18:51
	> так и запишем - восьмеричная система счисления тебе не далась. Ну попробуй программировать битовые поля в хардварных регистрах в восьмеричной системе, посмотрим надолго ли тебя в таком виде хватит. Восьмеричная система вообще де факто несколько изврат - ибо испытывает проблемы с границами байтов. А вот шеснадчатиричная - как влитая, 2 nibble == 1 byte. Поэтому я немедленно вижу что вон тот великий математик дал мне 25 битов и сказал что в 32 не лезет. А ты можешь попробовать этот фортель в троичной системе провернуть, угумс. > (а начинал бы не с доса а с нормальных систем на нормальных > компьютерах - знал бы, что двоичная форма нахрен не нужна) Ну да, ну да, попробуй маски для операций с битовыми полями скроить в восьмеричной системе, посмотрим через сколько ты спятишь как раз. А вот в 0b00101101 - как именно маска оно как раз отлично хайлайтит "биты интереса" в вооооон том регистре. А вот что такое 0x2D == 45 (dec) == (oct) 55? Ты отстроишь из этого числа на лету паттерн битов в регистре у себя в голове, чтобы понимать смысл действа?
	Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

	315. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от ffsdmad (ok), 26-Ноя-24, 08:15
	вы так дождетесь и вам ещё True-1 и True-2 подвезут
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

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

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

	169. Скрыто модератором	+/–
	Сообщение от Аноним (167), 24-Ноя-24, 13:22
	У Яфинна и кернел-девелоперов там Linux.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

	168. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 13:18
	Остается вопрос - а когда определена сущность.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

	246. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от anon2 (?), 24-Ноя-24, 23:05
	> За 16-ричную математику этот аноним^W mister_0 получает твердую двойку! Ибо 0x2000000 прекрасно лезет в 32-битный регистр, сумма 25 битов всего. 26 :)
	Ответить | Правка | Наверх | Cообщить модератору

	328. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (328), 26-Ноя-24, 15:05
	>> За 16-ричную математику этот аноним^W mister_0 получает твердую двойку! Ибо 0x2000000 >> прекрасно лезет в 32-битный регистр, сумма 25 битов всего. > 26 :) Вот, блин да, 25 битов - в каждом из операндов, а в вон том есть 25-й бит, но битов 26. Классичесий такой "off by one".
	Ответить | Правка | Наверх | Cообщить модератору

	145. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 11:45
	Есть регистр флагов, где валидность результата уже видна и не надо городить ваши фантазии.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	258. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от нах. (?), 25-Ноя-24, 11:49
	> у тебя не хватило бит и это оверфлоу > чтобы не было оверфлоу тебе надо что-то всё равно делать, это никогда > не халявно. ну проверка битика вообще-то почти халявная. Хз почему в низкоуровневом языке ее не стали предусматривать.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	56. "GCC 15 будет использовать стандарт C23 по умолчанию"	+6 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 01:16
	> int max - int a => int b Если значение "int a" отрицательное, будет переполнение при вычитание (underflow), которое тоже есть UB. В целом ваш коментарий показателен, типичный сишник не только не знает Си, но с умным лицом берется рассуждать о других языках.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	59. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от mister_0 (?), 24-Ноя-24, 01:33
	несомненно для отрицательных чисел нужно использовать min int, а ещё конечно не стоит забывать о представлении числа и в дополнительной форме отрицательных больше чем положительных на одно. но идея вполне понятна, если ты боишься оверфлоу, то можешь вполне всё проверить. эти проверки можно встроить или генерить автоматом, но они всё равно будут. хочешь быстро используй специальную инструкцию https://stackoverflow.com/questions/14523480/assembly-detect... один чёрт всё равно придётся что-то придумать, что делать, если оверфлоу
	Ответить | Правка | Наверх | Cообщить модератору

	64. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (64), 24-Ноя-24, 02:17
	> эти проверки можно встроить или генерить автоматом, но они всё равно будут. Вместо дорогой пред-проверки с явными сравнениями и несколькими ветками можно было бы использовать дешёвую пост-проверку регистра флагов, выражающуюся одним conditional jump'ом, вдобавок очень хорошо обрабатываемым branch predictor'ом. В C это невозможно сделать даже явно, а в современных языках это делается по умолчанию.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от mister_0 (?), 24-Ноя-24, 13:26
	>В C это невозможно сделать даже явно, а в современных языках это делается по умолчанию. ага ну конечно, это в каких так сделано? точно не в дебаг компиляции онли? Бранч предиктор хорош, но исполнение нескольких бранчей с одбрасыванием результатов ненужных тоже происходит. Ещё раз нигде бесплатно за программиста оверфлоу не обрабатывают, но для этого и есть программист, чтобы с этим разобраться.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (73), 24-Ноя-24, 04:04
	Сначала проверь, что оба положительные, потом вычти одно из max int, сравни со вторым, потом уже можешь складывать.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	189. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (189), 24-Ноя-24, 15:39
	> Сначала проверь, что оба положительные, потом вычти одно из max int, сравни > со вторым, потом уже можешь складывать. И во сколько раз у нас накроется скорость всей математики таким манером? Не хотите себе крипто или кодек которые разика в 3-4 тормознее того что у вас сейчас? Сможете с дотнетчиками и жабистами на равных зарубаться, а то что они пыль из под ваших сапог нюхают, давайте наравне с ними, а?! Хинт: нормальные люди не борятся с законами природы, они ими пользуются. Для unsigned - врап вполне well defined, и крипто вполне себе уповает что uint8/16/32 - врапается вполне характерным образом, дабы не делать лишние операции. К тому же условные операции - в крипто например текут инфо о характере обрабатываемой инфы. Так выполняется столько, а этак столько? Битик ключа такой-то, i++, и вот ваш офигенный 256-бит ключ угадывается за ... чтоооо, 256 забегов, глазом не успели моргнуть?! А вот врап - он вообще железный в большей части процов. А если даже и не железный то потток команд будет одинаковый.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Bottle (?), 24-Ноя-24, 09:20
	...и теперь ты нагородил кучу проверок на пустом месте, которые ещё надо писать руками, а не использовать заранее безопасные типы, определённые стандартом языка. В каком-то месте забудешь, и получишь overflow. И, что характерно, ты эти проверки реализуешь гораздо медленнее, чем квалифицированный разработчик компиляторов. В итоге твоя программа будет и медленной, и кривой.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	212. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (212), 24-Ноя-24, 16:56
	> ...и теперь ты нагородил кучу проверок на пустом месте, которые ещё надо > писать руками, а не использовать заранее безопасные типы, Что еще хуже - при запиле руками, "в лоб", тот же int a + int b <= INT_MAX это как бэ, UB, который не покажет -Wall -Wextra, лишь санитайзерв в рантайме, тут нужно что-то типа if(a < INT_MAX - b) x=a+b
	Ответить | Правка | Наверх | Cообщить модератору

	218. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (212), 24-Ноя-24, 17:07
	> if(a < INT_MAX - b) x=a+b ЧСХ, если b негативное число, то тут ... правильно, UB.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 11:52
	стандартный вопрос - какому числу равен min int?
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	190. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (189), 24-Ноя-24, 15:40
	> стандартный вопрос - какому числу равен min int? Вообще в макросне указано - чему он равен в конкретной системе. Как и максимальный.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Neon (??), 24-Ноя-24, 05:38
	А простое сложение расползается кучей кода с кучей багов. Спасибо, не надо
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	91. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (91), 24-Ноя-24, 06:22
	если a = -10, то при int max - int a будет оверфлоу > один if и тот сделать не могут, подавай им сразу новый язык, бороу чекер, безразмерную арифметику и прочее.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	122. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (122), 24-Ноя-24, 09:33
	Когда мне нужно было решить задачу проверки на переполнение, я использовал intprops.h из gnulib. Как более удобная обёртка, что ли. Тоже в итоге там какие-то подобные проверки.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	128. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (32), 24-Ноя-24, 09:55
	Зачем тебе тогда си если ты собрался это проверять на каждом сложении? Чтобы побольше поторомозить? Ну так тебе уже сказали джаваскрипт твой выбор. Переполнение к слову не единственная проблема. И ты их проверять на каждом сложении .. устанешь.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	170. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 13:22
	Если вам нужен язык для вычислительной математике - берите фортран и не пудрите мозги.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	105. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:41
	На практике ничего иного не наблюдается. Языки с иными свойствами почему-то миру ничего дать не смогли. Поэтому там может быть хоть в 10 раз больше багов - это никак не влияет на оценку.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	125. "GCC 15 будет использовать стандарт C23 по умолчанию"	–2 +/–
	Сообщение от Bottle (?), 24-Ноя-24, 09:43
	Практика не показатель качества - выживают не самые сильные и умные, а самые адаптированные. И в контексте рынка адаптация может означать широту поддержки и широкую популярность какой-то ОС, написанной на копроязычке (привет, Юникс) для PDP-11.
	Ответить | Правка | Наверх | Cообщить модератору

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

	131. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 10:10
	Показатель. Воровские лозунги ничего не стоят и не значат. Да и в целом рассказы про показатели имеют смысл только в контексте выбора. Здесь выбора нет - остальные языки не слабы, а просто не существуют. Поэтому сразу мимо.
	Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

	176. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 14:30
	>ты или дашь эти 32 бита, или профачишь вычисления. Для вычислений используйте Фортран.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	46. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 00:45
	> Потому что системный язык должен полагаться на то как происходит сложение > на аппаратном уровне в конкретной системе Угу, именно поэтому они это не implementation-defined, не хотя бы unspecified, а вот сразу UB! Что бы когда ты писал код, то как он будет работать было именно ХЗ, в зависимости от платформы, железа, флагов, степени безумия разраба компилятора, которые может просто выкинуть твой код нафиг с обоснование "не, ну не бывает же UB в нормальном коде".
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	54. "GCC 15 будет использовать стандарт C23 по умолчанию"	–2 +/–
	Сообщение от анон (?), 24-Ноя-24, 01:10
	Такова плата за генерацию эффективного кода. Никто же не заставляет использовать именно Си
	Ответить | Правка | Наверх | Cообщить модератору

	69. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 02:50
	> Такова плата за генерацию эффективного кода. Так ведь всё с точностью до наоборот. В Си надо обложить код if`ами чтобы не получить UB, но если у тебя модульная арифметика (в том числе знаковая) тогда на это можно положиться и писать эффективный код.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Bottle (?), 24-Ноя-24, 04:10
	О дааа! Тот самый эффективный код на Си, известный своими утечками памяти. А то, что указатели не обладают строгостью, как в Фортране, это мы конечно умолчим. И то, что "швитой штандарт" разрешает любым переменным занимать хоть 64 бита, лишь бы преодолевали минимальную границу длины от стандарта. Да, очень эффективное управление памятью для переменных вида int и float. Всего лишь в два-четыре раза больше положенного.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	152. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (166), 24-Ноя-24, 12:23
	Уже давно есть типы фиксированной ширины и контроль переполнения. Задирание ширины проистекает от неопределенности программистом масштаба вычислений. int + int = long int
	Ответить | Правка | Наверх | Cообщить модератору

	293. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Bottle (?), 25-Ноя-24, 17:27
	Всё это хорошо, ровно до тех пор, когда ты начинаешь писать код. И вдруг оказывается, что для float нет типов постоянной длины - да, на каждой платформе ошибки накопления будут свои. Удачи в отладке! И, к тому же, тебе придётся использовать библиотеки, которые, ВНЕЗАПНО, не используют эти типы. К сожалению, ты не можешь заставить весь мир писать так, как следует, а не так, как хочется.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Neon (??), 24-Ноя-24, 05:39
	Это называется халтура. На от@бись
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	106. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:44
	Если бы не заставляли. Все слёзы и ненависть обусловлена тем, что никаких иных языков кроме си не существует. А те, которые существуют номинально - на них ничего невозможно написать.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	120. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (73), 24-Ноя-24, 09:31
	Аноним написал много латинских слов, и думает, что написал что-то умное. А на самом деле, implementation-defined, unspecified и undefined, это буквально одно и то же. Что конкретно скрывается за UB, должно быть задокументировано в документации к компилятору.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	143. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 11:33
	Если для вас > implementation-defined, unspecified и undefined, это буквально одно и то же. то это прекрасно объясняет причины текущего состояния айтишечки)) Предлагаю открыть стандарт и вдумчиво прочитать 3.4.1, 3.4.3, 3.4.4. А заодно еще заглянуть в секцию "4. Conformance" и почитать к чему может приводить наличие UB в коде, в отличие от остальных.
	Ответить | Правка | Наверх | Cообщить модератору

	251. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (251), 25-Ноя-24, 09:37
	> А на самом деле, implementation-defined, unspecified и undefined, это буквально одно и то же. Да ладно! Если тебе эти "латинские" слова непонятны, засунь их в переводчик, и почитай по-русски. Они означают разные вещи. И *буквально* они тоже разные: там разные буквы. Очки одень и посмотри. > Что конкретно скрывается за UB, должно быть задокументировано в документации к компилятору. Да ладно! UB -- это undefined behaviour. Неопределённое поведение. Оно документируется как неопределённое, то есть компилятор оставляет за собой право делать всё что угодно. Или, если хочешь, C'шный стандарт оставляет за компилятором право делать всё что угодно.
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	47. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 00:46
	Ну давай, расскажи мне как ты собрался из Си "полагаться на то как происходит сложение на аппаратном уровне" если переполнение int`ов есть undefined behavior а не implementation-defined behavior.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	78. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Neon (??), 24-Ноя-24, 05:35
	Пусть на ассемблере кодят, раз им нужно сложение на аппаратном уровне в конкретной системе. Язык высокого уровня уже по любому абстракция
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	90. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от morphe (?), 24-Ноя-24, 06:13
	> Потому что системный язык должен полагаться на то как происходит сложение на аппаратном уровне в конкретной системе, а не воротить абстракцию над абстракцией лишь бы все было везде одинаково. Вот только всё современное железо реализует это как two's complement, и сложение везде переполняется. (Кроме каких-нибудь мейнфреймов на system z с binary-coded-decimals, но даже там C реализован не через это) Rust же гарантирует что сложение переполняется всегда, потому что стандартные числа в Rust всегда two's complement. (Что на каких-то абстрактных платформах может потребовать софтверной реализации, но таких фактически не существует) А в сях стандарт написан так, что сложение может происходить на абаках, а потому переполнение - undefined behavior, иначе говоря компилятор в праве оптимизировать код так, будто переполнения никогда не произойдут НА ЛЮБОЙ ПЛАТФОРМЕ.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

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

	104. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:39
	Просто они знают, что ub является переполнение, а не сложение. Поэтому у них всё работает.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	254. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (254), 25-Ноя-24, 10:51
	> КАК такое возможно в языке для системного программирования Вы видимо не системный программист, раз задаётесь таким простейшим вопросом.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	42. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от mister_0 (?), 24-Ноя-24, 00:37
	ну так ты проверь перед сложением или можешь после сложения в регистр flags посмотреть, там есть бит переполнения. а ещё есть люди которые рапэраунд с оверфлоу путают
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

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

	50. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от mister_0 (?), 24-Ноя-24, 00:53
	ну придётся ассемблерную вставку сделать.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 01:04
	> ну придётся ассемблерную вставку сделать. А ничего что на сях мы писали - чтобы портабельно было, м?!
	Ответить | Правка | Наверх | Cообщить модератору

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

	191. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (191), 24-Ноя-24, 15:45
	> Вы писали на сях, чтобы было быстро, а не чтобы было портабельно. Мы писали на сях - чтобы было и быстро и портабельно, ага! :) > Оптимальное соотношение между скоростью разработки и скоростью работы программы. И именно поэтому логично брать размеры переменных - того размера которого уместно в энной задаче. Более того - это иногда как раз оптимизация. Скажем "int" в AVR по дефолту 16 битов и это в принципе 16-бит операция. Замена на явный uint8_t в каком-нибудь цикле может улучшить код, если я точно могу гарантировать что счетчик никогда не более 255. И тогда оно будет телепать 1 регистр x8 а не 2 x8 при случае. Конечно есть некий шанс, что оптимизер на таком уродце и int обрубит до 8 битов если по диапазону влезло - но вот это уже ниоткуда не следует.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 13:29
	Для портабельно используйте Java. Си это быстрота и гибкость.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	192. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (191), 24-Ноя-24, 15:46
	> Для портабельно используйте Java. Си это быстрота и гибкость. Для непортабельного у нас уже был ассемблер, но пример Colibri OS почему-то намекает как делать не стоит... :). А свою энтерпрайзятину - кушайте сами.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "GCC 15 будет использовать стандарт C23 по умолчанию"	+3 +/–
	Сообщение от Neon (??), 24-Ноя-24, 05:40
	А на хрена тогда С нужен ? Если нужно сразу на ассемблере фигачить
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	51. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от mister_0 (?), 24-Ноя-24, 00:55
	но я выше ответил, что проще считать post condition выводить weakest predicate и проверять его до вызова и никаких тебе оверфлоу. или ты думаешь, что только использования раста и питона это единственный способ?
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

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

	108. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:48
	Пистон написан на си, поэтому там ситуация таже самая. Раст компилируется си компилятором, поэтому ситуация снова такая же. Хоть паскалик бы в пример привёл - не настолько позорно было бы.
	Ответить | Правка | Наверх | Cообщить модератору

	137. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 10:45
	Ты глупость написал и даже не покраснел. Если я напишу на PHP компилятор языка Х в машинный код, его поведение никак не будет связано с, собственно, PHP.
	Ответить | Правка | Наверх | Cообщить модератору

	139. Скрыто модератором	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 10:59
	Просто ты рядовой ретранслятор пропаганды. Раст компилируется не компилятором написанным на си, а компилятором си. Обладающим всеми свойсвами си и всеми недостатками си. На чём он там написан не важно(хотя и очевидно на чём).
	Ответить | Правка | Наверх | Cообщить модератору

	179. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 14:40
	Эвоно как, Михалыч! Оказывается LLVM это не оптимизирующий бэкенд, а всего-то компилятор Си. Надо им issue на гитхабе открыть, пацаны то не знают.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 11:38
	> Раст компилируется си компилятором Это не соответствует действительности. Фронт раста компилируется внезапно компилятором на расте. А бек - это llvm, который написана на современном с++, а не окаменелой мерзопакостной дыряшке. Да и даже если допилят gcc-rs, то gcc это сейчас тоже с++. Даже до них дошло что писать на сишке серьезные вещи не продуктивно.
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	150. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 12:01
	Соответствует, просто ты ангажированный агитатор, спамящий агитки. "написано на си/не на си" - агитатор не заметил, что я не писал что раст компилируется написанным на си или не на си. "есть гццрс" - агитатор спорит с тезисом "раст компилируется си компилятором" и показывает компиляцию раста си компилятором. "компилятор на расте" - которого не существует и где компиляцией занимается си компилятор.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:45
	В си. __builtin_*_overflow() - 1000 лет есть.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	119. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 09:21
	Нет, похоже всё ещё хуже - там в новости написано "Добавлена поддержка заголовочных файлов <stdckdint.h>". Это даже в стандарте теперь есть, но почему-то эксперты говорят "в си нет способа".
	Ответить | Правка | Наверх | Cообщить модератору

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

	194. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 15:59
	Очередное умножение агитатора на ноль. Сначала он рассказывал, что нет способов. Потом, когда эти способы показали, начал рассказывать "ну раньше не было, только сейчас появились". Если ткнуть его носом уже в это враньё - он начнёт мазаться "ну это не по дефолту"/"а можно не использовать эти способы"/"я не понимаю что делаю, поэтому меня нужно принуждать к конкретному и единственному решению". И так далее.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 01:04
	> ну так ты проверь перед сложением или можешь после сложения в регистр > flags посмотреть, там есть бит переполнения. В сях нет стандартного способа посмотерть флаги, внезапно. > а ещё есть люди которые рапэраунд с оверфлоу путают Wrapround определен и гарантирован только для unsigned, если что.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	82. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Neon (??), 24-Ноя-24, 05:41
	> В сях нет стандартного способа посмотерть флаги, внезапно. Такой системный язык))). Близкий к аппаратуре
	Ответить | Правка | Наверх | Cообщить модератору

	97. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 07:28
	>> В сях нет стандартного способа посмотерть флаги, внезапно. > Такой системный язык))). Близкий к аппаратуре Внезапно он еще и про портабельность. А имплементация флагов у разных процов - довольно разная бывает. Так что - ограничения жанра, скажем так. В парадигмах C вообще возможны как таковые только mem-mapped доступы. Если нечто не отмаплено в память - ну, этого нет. На память об этом вся современная периферия как раз mem mapped, а всякие io пространства - легаси. Заодно mem mapped железки и DMA удобны, чего уж там. Самый лучший код - это его отсутствие!
	Ответить | Правка | Наверх | Cообщить модератору

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

	195. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (195), 24-Ноя-24, 16:06
	>> В парадигмах C вообще возможны как таковые только mem-mapped доступы. > Ну, у C есть ещё стандартизированные* расширения из ISO/IEC TR 18037. Среди > которых named address spaces** и iohw.h. Ну вот такой вот хреновый стандарт, со звездочкой и 5-м шрифтом :) > Флеш-память и EEPROM в AVR не отмаплены на адресное пространство RAM и > требуют других инструкций, но с расширением компилятор сам их будет вставлять. 1 из многочисленных причин по которым AVR - слился. > Хоба: > __eeprom volatile unsigned char ee_var = 0xff; // IAR > const __flash int array[] = { 3, 5, 7, 11, 13, 17, > 19 }; // GCC Хоба, __eeprom и __flash не являются стандартными квалификаторами си, да еще - разные в разных компилерах, вау. А на СortexM наппример - const int arr[] = {2, 3, 7}; уйдет в RODATA (flash) сам, а не будет RAM жрать как на аврине глупой. Отличный мастеркласс от фирмы ARM что удобно си и програмерам, и почему линейные пространства рулят. Теперь попробуй DMA этого -> периферия? Ох, у уродца AVR и DMA нету, так что тщедушное ядро еще и должно само нестандартно дергаться на это? Ок, +1 гвоздь в крышку гроба. Ибо ЭТО сейчас умеет вон тот 20-центовый RISCV на его горе (DMA автомат и uncore вообще там "STM32-like"). > С одной стороны, всё-таки расширение, а не чистый язык. А с другой > стороны, на расширение аж стандарт есть, это не линуксовые гнутости. Реально это +1 причина забыть о AVR навсегда. В мире где за 20 центов продают RISCV с DMA, не имеющего такие проблемы, его время определенно вышло. > Если бы отдельные пространства прижились, то расширение бы и в язык перекочевало. Вместо этого брейнфака нормальные люди сделали mem-mapped периферию. И с ней работать на порядок проще, в нее можно DMA зарядить и все такое. И пока вы на малохольном ядре таскаете байты из флешки сами, 20-центовый китаец заряжает весь блок данных в периферию DMA и 32-бит проц вообще идет заниматься своими делами, забыв об этом. Во сколько раз суммарно это обставляет AVR - особенно с учетом цена/фичи - ну вы поняли.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 24-Ноя-24, 18:33
	Ну блин, это была не реклама AVR, а история про то, что если не отмаплено, то в C ещё не всё так однозначно из-за этих "Extensions for the programming language C to support embedded processors". У C++, например, нет таких стандартных расширений и раздела Common extensions в стандарте нет. AVR очевидно устарел, сейчас он выглядит как учебное пособие - там всего немного и задокументировано хорошо, даташит - маленький, набор команд - маленький, тулчейн от GCC - маленький; не заблудишься. Контроль за размещением в SRAM vs Flash всё равно может пригодиться, скорость чтения-то разная.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 20:32
	> Ну блин, это была не реклама AVR, а история про то, что > если не отмаплено, то в C ещё не всё так однозначно > из-за этих "Extensions for the programming language C to support embedded > processors". А таки вон те кейворды... 1) Нестандартны от слова вообще. 2) Здорово нагибают портирование кода на/с AVR. > У C++, например, нет таких стандартных расширений и раздела Common extensions в стандарте нет. У C вон те кейворды тоже - не есть что-то стандартное и на практике такое поведение AVR очень нагибает interop в целом. > AVR очевидно устарел, сейчас он выглядит как учебное пособие - там всего > немного и задокументировано хорошо, Но вот отдельные адресные пространства на сишке это как раз их фирменная боль. С диким жором оперативы которой мизер при случае, на константы. И вот это норвежцы считали удобным для си. ИМХО ARM умнее сделал в >= Cortex M3, сделав нейманом по логике и гарвардом по физике. > даташит - маленький, набор команд - маленький, При том тупой как дрова. Понятия bad opcode вообще нет. И вообще исключений как таковых. А заодно - ну вот и ubsan им тогда не положено, раз такая фигня, насколько я понимаю. Он на минималках может же просто bad opcode вызывать в точке срабатывания, так он даже для МК катит. > тулчейн от GCC - маленький; не заблудишься. Ну я б не назвал его маленьким. И он очень интрузивный, с всеми определениями под капотом, кастомными линкерскриптами которые не особо видны так сразу, какие-то либы самопальные. > Контроль за размещением в SRAM vs Flash всё равно может пригодиться, скорость > чтения-то разная. На мой вкус, RODATA по умолчанию должен быть - в флеше. Просто потому что его сильно больше. А контроль нормально делается, пардон, __attribute__((section("whatever")) на объекте. Так можно даже бутлоадер до фирмвари оформить например. Интересно, это запилили вон там в виде с квадратными скобками? И конечно как максимум как гнутое расширение небось...
	Ответить | Правка | Наверх | Cообщить модератору

	317. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 26-Ноя-24, 09:08
	> А таки вон те кейворды... > 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.
	Ответить | Правка | Наверх | Cообщить модератору

	329. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 26-Ноя-24, 16:09
	> Но всё-таки есть стандарт на добавление подобных кейвордов... Но называя вещи своими именами - это не сработало. Де факто - подобный код не портабельный, от слова вообще. Как по мне, если говорить о всяких псевдо/недо/типа-стандартах, я для себя предпочитаю вообще немного иной подход, типа "Embedded C Coding Standard". Он как таковой - не стандарт, в том его понимании. Но отличный набор гайдлайнов как писать надежный, безграбельный код, вместе с MISRA и тому подобными вещами, типа советов от Cyan на тему antibug'а. Это спасает от множества горя. И круто когда софт просто работает. Сразу, без хардкора с дебагом. > Наоборот, они избавляют от pgm_read_byte, то есть приближают к современным архитектурам Какая мне при сборке проекта разница - непортабельный кейворд нагнет, или pgm_read_byte? Что так не портабельно, что сяк. Это boolean - без дополнительных квалификаторов. Или билдится без изменений, или нет. > (убрать 1 слово __flash проще, чем убирать все вызовы pgm_read_byte). Что совой о пень, что пнем о сову. Более того - если копнуть, в результате окажется что у авр есть такие указатели и есть разэдакие, это разные вещи и в целом - это брейнфак, господа. А также нельзя код из RAM выполнять, etc, так что про внешние модули диагностики или калибровки можно забыть. >> При том тупой как дрова. > Вот, неплохое свойство для учебного пособия. К плохому приучать - ничего хорошего нет. Потом начинает заваливать глюкавыми софтварными инверторами и тому подобным гуано, где ключи делают пых когда пофигстичный проц все же поймал клин и не вышел из него за обозримое время. А почему такой проц? Что знали - то и вкатили! >> Ну я б не назвал его маленьким. > Хрен знает, с чем тут можно спорить. Берём STM32 и вроде как > официальный современный способ работы с ним. Снизу CMSIS, над ним LL, > над ним HAL, а над ним его графическое величество STM32CubeMX. А можно на это все забить - и програмить его как обычно. Я вообще Cortex M умею с ноля подымать, вплоть до лично моего стартапа. С авриной это сложнее - куча дефолтовых стартапов, линкерскриптов, дефайнов, регистров, отделаться от всей этой требухи чтобы САМОМУ посмотреть что НА САМОМ ДЕЛЕ надо чтобы САМОМУ поднять камень, С НОЛЯ - на авр крайне геморно. И эти люди будут рассказывать про уровни и слои? Ну вот нет! :) А еще освоение STM32-like uncore это очень ценный актив. Это понимание позволит работать и с китайскими клонами ARM, с вон теми RISCV за 20 центов, ибо CPU core сменили, но uncore - все тот же косплей STM32. Это такой x51 2.0/3.0 получился, только для периферии, которая в МК главное. AVR с периферией нечего ловить, их uncore не менее печально чем cpu core. > Вот avr-gcc, который фьюзы позволяет прямо в коде прописать, вот прямо над > main(), а вот махина, производитель которой настоятельно рекомендует настраивать > микроконтроллер с помощью кодогенерации через графическую утилиту. Вот avr-gcc с какой-то левой либой от чуть ли не атмела, автоматически впихиваемыми линкер скриптами, 100500 дефайнов, с регистрами - далеко не в лучшем стиле делания этого ... и теперь найдите хоть 1 чела который без этих подпорок поднимет AVR'ину, САМ и С НОЛЯ? Т.е. си - чисто как кодогенератор, без того обвеса и подпорок "от богов". А то вы все это вещаете тому кто для Cortex M сам так на пантеон сходил, без вот этого вот. >> А контроль нормально делается, пардон, __attribute__((section("whatever")) на объекте > Нормально делается там где нормально сделано, а на AVR такой подход, только > в виде __attribute__((__progmem__)), возвращает нас к необходимости в pgm_read_byte. Ну как бы AVR вообще довольно похабная штука с точки зрения продвинутого программирования на сях или плюсах. Конечно для serial.begin и это - проц. А чуть попродвинутее.. и это боль.
	Ответить | Правка | Наверх | Cообщить модератору

	340. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 26-Ноя-24, 23:17
	С одной стороны, там поднимать почти нечего и в даташите почти всё есть. С другой стороны, я сам про avr-gcc заговорил; если плясать от того, что он даёт, то даёт он ребусы ("отыщи, где зануляется bss" и т.д.), которые предлагается использовать as is. Есть такое, это место слабое.
	Ответить | Правка | Наверх | Cообщить модератору

	341. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 27-Ноя-24, 00:29
	> С одной стороны, там поднимать почти нечего и в даташите почти всё есть. Почти не считается. Даже просто самому определить регистры AVR'ки - брейнфак. Ибо оказывается исторически у какахи 2 разных идеи насчет адресов регистров в io space, при том конечно же гениям в какой-то момент адресов не хватило - и есть "старые" адреса, и есть "новые". Вот это я понимаю, как сделать качественный, кондовый брейнфачише абсолютно на ровном месте. Cortex M после этого выглядит просто как masterpiece. И даже RISCV за 20 центов на фоне этого неплох, ибо с правильной штуки содран. > С другой стороны, я сам про avr-gcc заговорил; если плясать > от того, что он даёт, то даёт он ребусы ("отыщи, где > зануляется bss" и т.д.), которые предлагается использовать as is. Есть такое, > это место слабое. Ну и вот именно обучиться по нему как например платформу с ноля bring up'нуть - ну, гм, я бы сказал что для Cortex M с тем же GCC это оказалось в разы проще.
	Ответить | Правка | К родителю #340 | Наверх | Cообщить модератору

	268. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от фф (?), 25-Ноя-24, 13:23
	вот кстати, сюда же можно было бы замапить регистры процессора и проверять бит переполненности, например.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	112. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:55
	> В сях нет стандартного способа посмотерть флаги, внезапно. Не позорься - написал выше этот способ. > Wrapround определен и гарантирован только для unsigned, если что. Опять же, нужно меньше позориться. ++*(unsigned*)&int_var - переполняй сколько хочешь.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	148. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 11:52
	> переполняй сколько хочешь. Поздравляю. Своим костылем с кастом к unsigned вы только подтверждаете что проблему UB, что убогость сишки в целом. Продолжайте в том же духе))
	Ответить | Правка | Наверх | Cообщить модератору

	196. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (195), 24-Ноя-24, 16:13
	>> В сях нет стандартного способа посмотерть флаги, внезапно. > Не позорься - написал выше этот способ. Тебе там уже написали что ты облажался. А, ты за добавкой пришел? Ну я тебе ее отсыплю, синьор-помидор. >> Wrapround определен и гарантирован только для unsigned, если что. > Опять же, нужно меньше позориться. ++*(unsigned*)&int_var - переполняй сколько хочешь. От того что ты накастовал это как unsigned - формат хранения (signed) int в памяти определеннее не станет. А то что ты приказал считать это unsigned и даже для unsigned оно определено, вовсе не гарантирует ожидаемый результат в именно signed, просто потому что это ниоткуда не следует в общем случае ;) Хотя комитет придурков это утомило - они с C23 все же как я помню утвердили, что signed теперь только two's complement. Но - не, сделать это нормально их не хватило, и все равно - UB местами оставили. Фйэспалм, лол. Или как сделать все на 90% и профачить весь профит остальными 10% долбоклюизма.
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	103. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:38
	Судя по всему решение хорошее. Как иначе объяснить, что весь софт написан на этой дикости, а на чём-то ином не аписано ничего.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	222. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 17:22
	Весь нормальный софт написан на плюсах. Даже самый сишный компилятор гцц и тот не осилили на сишке продолжать. А на сишке или легаси нуано, или упертый Айм Финнишь, который просто не хочет признать свою ошибку. А до с++ была ада. Но быдлокоделам было легче писать на си.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 14:27
	Если по факту UB, то и объявить надо, что - UB.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

12. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
Сообщение от Аноним (12), 23-Ноя-24, 22:46
Значит ли это, что gcc 15 будет поддерживать стандарт c23 ПОЛНОСТЬЮ?
Ответить | Правка | Наверх | Cообщить модератору

15. "GCC 15 будет использовать стандарт C23 по умолчанию"	+9 +/–
Сообщение от Маковод (?), 23-Ноя-24, 23:02
Всё это ерунда, есть же православный ANSI C (C89). Всё остальное — ненужный реверс инжиниринг с синтаксическим сахаром.
Ответить | Правка | Наверх | Cообщить модератору

	16. "GCC 15 будет использовать стандарт C23 по умолчанию"	+6 +/–
	Сообщение от Маковод (?), 23-Ноя-24, 23:03
	Овер инжиниринг* (будь проклята автозамена)
	Ответить | Правка | Наверх | Cообщить модератору

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

	41. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 00:34
	> Всё это ерунда, есть же православный ANSI C (C89). Всё остальное — > ненужный реверс инжиниринг с синтаксическим сахаром. Вот ты на нем и прогай. А я меньше чем на C99 в принципе не согласен, а лучше минимум 11, ибо делать из г-на и палок аналог static assert'а - ну такое себе.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	277. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (277), 25-Ноя-24, 15:06
	Будь мужиком, не останавливайся на C89! Используй триграфы!
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

18. "GCC 15 будет использовать стандарт C23 по умолчанию"	–2 +/–
Сообщение от nc (ok), 23-Ноя-24, 23:26
Расширения GNU давно пора принимать в стандарты С и С++. Простые и полезные идеи, уже давно реализованные и многократно проверенные. Единственное чего не хватает - расширения __declspec(property) в С++, которое есть в msvc и clang, но нет в gcc.
Ответить | Правка | Наверх | Cообщить модератору

	135. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 24-Ноя-24, 10:29
	> в стандарты С Нет, C практически заморожен. И не один GCC имеет власть - не захотят остальные реализовывать фичу, её из стандарта удалят (история с Microsoft, C11 и VLA (нет, то, о чём я говорю не вернули в C23)). > и С++ А он шевелится, но Страуструп постоянно говорит, что надо избегать фрагментации и создания несовместимых диалектов. Если сделать вид, что расширений GNU не существует, то и фрагментации языка они не вызывают - примерно так это работает. Вызывают, конечно, но это уже не головная боль комитета, поэтому будем считать, что не вызывают. Но народ пользуется расширениями и комитет описывает какой-то полумифический язык? Как хорошо, что это не проблема комитета. У стандартного C++ слишком много требований совместимости (обратной, API'шной, ABI'шной, в некоторой степени даже прямой, [s]диагональной[/s]), они язык тормозят и медленно-медленно погубят.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:23
	>> в стандарты С > Нет, C практически заморожен. И не один GCC имеет власть - Де факто актуальные компилеры C это GCC и Clang. > не захотят остальные реализовывать фичу, её из стандарта удалят (история с Microsoft, > C11 и VLA (нет, то, о чём я говорю не вернули в C23)). Майкрософт хотя-бы C99 уже смог в своих недоделках, чтобы им там еще про C23 что-то заикаться вообще? :) С VLA грабли по другим причинам. Ибо это - как правило аллокация на стеке (не так уж важно, но все усугубляет - его размер не бесконечен). При том - хрен его знает сколько доступно было, это ДО аллокации узнать нельзя. А если не получилось - узнать это можно только крахом/жесточайшим UB. Что для системного языка не предел мечтаний. Т.е. заведомо интерфейс для прострела пяток, вместе с коленками и черепом заодно, вообще без возможности корректной реакции на нехватку аллокации потенциально-большого объекта. > создания несовместимых диалектов. Если сделать вид, что расширений GNU не существует, > то и фрагментации языка они не вызывают - примерно так это работает. Расширения GCC просто периодически втягивают в стандарт. И в C и в C++. После чего майкрософт как зайчик идет имплементить - или noncompliant и не может декларить этот стандарт. > У стандартного C++ слишком много требований совместимости (обратной, API'шной, ABI'шной, > в некоторой степени даже прямой, [s]диагональной[/s]), они язык тормозят и медленно-медленно > погубят. У C++ так то разные версии есть...
	Ответить | Правка | Наверх | Cообщить модератору

	220. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 24-Ноя-24, 17:15
	> Майкрософт хотя-бы C99 уже смог в своих недоделках, чтобы им там еще про C23 что-то заикаться вообще? :) > или noncompliant и не может декларить этот стандарт. Так ты 2+2 написал, а сложить не сложил. Я сложу: из C99 выкинули VLA, C99 стал C11, стандарт C11 Microsoft и задекларил. > Де факто актуальные компилеры C это GCC и Clang. Актуальность - это одно, а количество власти в комитете - другое. > С VLA грабли по другим причинам Не важно, GCC от него не отказался (и в микроконтроллерах не опаснее, чем использование кучи, а в общем-то безопаснее). > У C++ так то разные версии есть... Но надо и понимать глубину наших глубин. Новую версию нельзя расширять радикально, потому что от языка требуется некоторая прямая совместимость. В proposal'ах серьёзно пишут: "backward and forward compatibility"[1]. "WG21 is supposed to protect against dialects"[2] "There is a reasonable fear that attributes will be used to create language dialects"[3] "Unless done extremely carefully, the “modernized C++” would suffer from the problems encountered with “Safe C” languages: the inability to interoperate sufficiently smoothly with older C++ constructs to avoid needing to become a self-sufficient subset of a much-enlarged C++ language"[4] [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p18... [2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... [3] https://stroustrup.com/C++11FAQ.html#attributes [4] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p26...
	Ответить | Правка | Наверх | Cообщить модератору

	223. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 24-Ноя-24, 17:28
	> потому что от языка требуется некоторая прямая совместимость То есть требуется не только чтобы старый код работал в новых компиляторах (обратная совместимость). но и хорошее взаимодействие между старым и новым кодом. То есть старый код тянет назад будущие версии языка. Это как если бы в JS не стали добавлять "use strict", потому что он диалект создаёт. Проблему даже сложно осознать, но в C++ она есть.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 21:22
	> Так ты 2+2 написал, а сложить не сложил. Я сложу: из C99 > выкинули VLA, C99 стал C11, стандарт C11 Microsoft и задекларил. У них, помнится, далеко не только VLA не хватало, по жизни. Народ заманался ждать пока они растормозятся - и посваливал на другие компилеры. Это то что господа получают за тормозизм и забивание на си. У них там то плюсы были, то неты, а си - где-то в ауте. Ну все кому надо было си - оттуда и свалили. Вот буквально все алгоритмисты и системщики которых я знал - теперь лю gcc или clang. Даже (полу)проприетарщики виндовые. Такой пируэт истории. >> Де факто актуальные компилеры C это GCC и Clang. > Актуальность - это одно, а количество власти в комитете - другое. Не видел особой активности ms в этом комитете. И лично я о VLA скучать не буду. Сыкотная фича. Весь мой код по жизни обложен -Wvla. Ибо нафиг-нафиг ВНЕЗАПНЫЕ срывы стэка неконтролируемой аллокацией. Так что - даже от майкрософта польза может быть, если все так как вы вещаете. >> С VLA грабли по другим причинам > Не важно, GCC от него не отказался Вообще-то -Wvla это стандартный флаг для такого кода. > (и в микроконтроллерах не опаснее, чем использование кучи, а в общем-то безопаснее). На ошибку malloc() можно среагировать. Ошибка вон того - просто выносит стэк к хренам и дальнейшее полностью undefined. Нет никакого способа узнать сколько безопасно, а о том что не безоапсно узнаешь лишь по факту, прострелом черепа. За юзеж такого в МК гнать надо цаными тряпками, имхо, из профессии. Все нормальные програмеры юзают -Wvla. >> У C++ так то разные версии есть... > Но надо и понимать глубину наших глубин. Новую версию нельзя расширять радикально, > потому что от языка требуется некоторая прямая совместимость. Некоторая. И таки - часть вещей deprecated все же сделали. И кому не нравится, извольте компилить в режиме старой версии стандарта. С C23 будет аналогично. Не можете комплайнс с стандартом - компильтесь как более старый стандарт! > В proposal'ах серьёзно пишут: "backward and forward compatibility"[1]. Но реально - до известного предела. > "WG21 is supposed to protect against dialects"[2] Dialects это всякие форки и неофициальные отшнуровки. А конформанс той или иной версии стандарта того или иного сорца - отдельный топик. То что некто соответствовал C++11 не значит что он автоматом C++2x будет. Равно как C89 сорец не станет сорцом C23 по взмаху волшебной палочки. Компильте в ту версию стандарта которую сорц таргетировал. > sufficiently smoothly with older C++ constructs to avoid needing to become > a self-sufficient subset of a much-enlarged C++ language"[4] Тем не менее то что старый сорец соберется в режиме нового стандарта никто никому никогда не гарантировал, ни в си ни в си++.
	Ответить | Правка | К родителю #220 | Наверх | Cообщить модератору

	318. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 26-Ноя-24, 11:08
	> За юзеж такого в МК гнать надо цаными тряпками, имхо, из профессии. Нет, вас. 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(++) сейчас вот как сбросят груз обратной совместимости, да как покажут. Просто запрягают долго, ага.
	Ответить | Правка | Наверх | Cообщить модератору

	323. Скрыто модератором	+/–
	Сообщение от Аноним (244), 26-Ноя-24, 12:32
	> обратной совместимости > обратной * и прочая, и прочая совместимости.
	Ответить | Правка | Наверх | Cообщить модератору

	324. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от fuggy (ok), 26-Ноя-24, 14:03
	Да кто же эту MISRA будет использовать. Если это не критическая программа, то никто это использовать не будет. А если критическая, то они использует это и без MISRA и всё равно ошибки допускают. Вот если бы это было встроено в компиляторы на уровне варнингов. А так как нужно для оптимизации иногда ходить по тонкой грани UB они от этого плюются.
	Ответить | Правка | К родителю #318 | Наверх | Cообщить модератору

	330. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 26-Ноя-24, 17:05
	> Нет, вас. 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 каким, пусть под ним и компилится, явно запросив именно этот стандарт.
	Ответить | Правка | К родителю #318 | Наверх | Cообщить модератору

38. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (-), 24-Ноя-24, 00:23
llvm не лучше? обоснуйте
Ответить | Правка | Наверх | Cообщить модератору

	115. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 09:04
	Хуже. ``` int f(int* p, int a) { p = __builtin_assume_aligned(p, a); } ```
	Ответить | Правка | Наверх | Cообщить модератору

40. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
Сообщение от Аноним (-), 24-Ноя-24, 00:31
> атрибут [[noreturn]] позволяет указать, что функция не возвращает значений Вообще-то он указывает что функция никогда не возвращается. Скажем main в фирмвари - возвращаться некуда и его можно задекларить так (экономит немного кода в прологе функции).
Ответить | Правка | Наверх | Cообщить модератору

	263. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (237), 25-Ноя-24, 12:18
	Тоже глаз зацепился. Думаю: что, void отменили, что ли?
	Ответить | Правка | Наверх | Cообщить модератору

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

58. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (58), 24-Ноя-24, 01:20
14 версия при сборке пакетов ругалась на указатели, 15 будет ругаться если код не той версии. Страшно представить на что 16 версия ругаться будет.
Ответить | Правка | Наверх | Cообщить модератору

	281. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от _kp (ok), 25-Ноя-24, 16:07
	Если не указываете явно с каким стандартом Си компилировать исходник, то не все ли равно. :)
	Ответить | Правка | Наверх | Cообщить модератору

70. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
Сообщение от мяв (?), 24-Ноя-24, 02:59
что-то фигня какая-то с auto.. auto myNum = superCalculator(2,2); и иди гадай, кого там возвращает твоя функция. а потом твой друг пойдет гадать и лазать в соседнем файле, когда откроет код .. псоле чего окажется, что эту фцнкцию где-то там по дороге перекрыли/перепилили/вовсе другой файл включили и она тперь возвращает int, вместо uint :| зачем вообще такое добавлять в язык со сторой типизацией? ну, серьезно, это ж лол какой-то. послезавтра эта функция будет char* возвращать. и я, вместо жалобы на неправельный тип в декларации, увижу 100500 жалоб в черт пойми, каких частях кода. а auto молча станет char*.
Ответить | Правка | Наверх | Cообщить модератору

	71. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от мяв (?), 24-Ноя-24, 03:00
	я ж правильно логику работы auto поняла?
	Ответить | Правка | Наверх | Cообщить модератору

	84. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Neon (??), 24-Ноя-24, 05:43
	Какие проблемы ? Смотрим объявление функции. В современных IDE это автоматом подсвечивается при наведении на функцию
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	161. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Аноним (166), 24-Ноя-24, 12:49
	А без IDE и AI уже никуда?
	Ответить | Правка | Наверх | Cообщить модератору

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

	86. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Илья (??), 24-Ноя-24, 05:48
	Значит, типизация не строгая. Должно сломаться всё по цепочке. А то, что ты тип возвращаемого значения меняешь в публичном апи - это отдельный вопрос
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	163. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 12:57
	Ну неявно это можно понимать как тип "возвращенный функцией". Освобождает от знания интерфейса функции, но оставляет вопросы сопряжения с другими типами. В си никогда не было строгой типизации. Была идея "адаптивной типизации".
	Ответить | Правка | Наверх | Cообщить модератору

	351. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Илья (??), 28-Ноя-24, 05:58
	Не понял. Что такое адаптивная типизация?
	Ответить | Правка | Наверх | Cообщить модератору

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

	331. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 26-Ноя-24, 17:26
	> Си вообще забавная штука. Вроде низкоуровневый, но функция на самом деле может > и получить и вернуть даже struct. причём для передачи структуры по значению ABI требует, чтобы все её поля бережно засунули в стек по одному. нет, не просто блоб-структуру, которую можно потом нормально адресовать, а поля один за одним, как будто это обычные параметры соответствующего типа. мне даже не хочется представлять, чем закидывался тот, кто это придумал.
	Ответить | Правка | Наверх | Cообщить модератору

	342. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 27-Ноя-24, 00:43
	> причём для передачи структуры по значению 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 и доразвито.
	Ответить | Правка | Наверх | Cообщить модератору

	343. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 27-Ноя-24, 01:21
	> Сам по себе стандарт C не регламентирует никакие ABI. успехов писать на «стандарте си». как удобно: когда надо — down to earth, инженер-практик. а когда не надо — будем про сферические стандарты. > Ты про которое из ABI и под какую архитектуру? про x86. >> нет, не просто блоб-структуру, которую можно потом нормально адресовать, > Насколько я помню, union на struct вида array[N] - вполне валидная идея > вроде. это всё прекрасно — вот только выравнивание аргументов в стеке во-первых, не обязано совпадать с таковым у структуры, а во-вторых, порядок полей может оказаться перевёрнут из-за calling convention. ура, бедный компилятор вынужден или переписывать весь код внутри функции, которому не повезло со структурой работать, или собирать её обратно во временную переменную, расходуя таким образом стек дважды. отличное решение, чудесные парни придумали. >> а поля один за одним, как будто это обычные параметры соответствующего типа. > И как это выглядит для uint8_t something:2, somethingelse:3 ? а так и выглядит: как инты. на размерность после двоеточия плевать. впрочем, может именно тут пакуются — этого я точно не помню, конкретно в этом месте могу ошибиться.
	Ответить | Правка | Наверх | Cообщить модератору

	361. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 28-Ноя-24, 19:26
	>> Сам по себе стандарт 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 такая штука точно не подгонит.
	Ответить | Правка | Наверх | Cообщить модератору

	363. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 28-Ноя-24, 20:24
	>>> Сам по себе стандарт 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 этого подразумевается упаковка. ты специально делаешь вид, что не можешь запомнить тему обсуждения, и типа-отвечаешь на совсем не относящееся к?
	Ответить | Правка | Наверх | Cообщить модератору

	372. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 06:06
	> правда, они даже ввод и вывод делать не могут — потому что > в языке си нет таких операторов. очень полезно. А <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 я вообще не силен - ибо для меня это настолько легаси что я просто не собираюсь раскапывать эти кости уже. И за нормальный проц это я ессно не считаю. Дедушка славно поработал, ему пора на пенсию. А вот си переживет и тебя, и меня.
	Ответить | Правка | Наверх | Cообщить модератору

	374. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 30-Ноя-24, 06:25
	>> правда, они даже ввод и вывод делать не могут — потому что >> в языке си нет таких операторов. очень полезно. > А <stdio.h> это что, мой глюк? ух ты, это у нас теперь часть языка. эвона как. >> динамической памяти нет… ничего нет, короче. это всё, на минуточку, библиотеки. > Ну я и не обещал что ты POSIX приложуух на мк без > изменений запустишь. как это? ты же выше сам сказал, что это часть языка. > Для меня x86-32 по сути не существует уже. Это махровое легаси, о > котором лично я скучать не буду. Все мои x86 системы 64-битные, > даже 32 бит либ не установлено, 64 бита end to end. бывает, чо. «все побежали — и я побежал.» дополнительный штрих к твоему неумению оценивать технологии самостоятельно, а не по чужим мнениям. >> и то, что одна структура может иметь несколько видов в пределах одной >> программы — тоже. > Я вообще не понимаю нужду шарахаться по struct "raw" доступом. потому что ты в жизни ни одного серьёзного компилятора не написал. поэтому ты так и не понял, о чём я речь вёл. хрен его знает, зачем ты попытался зарубиться со мной на теме компиляторов, ничего в этом не понимая. >> а ничего, что это меняет семантику программы, потому что получается передача по >> ссылке? хотя какая ерунда, кого та семантика волнует… > Меняет. Но так как правило даже удобнее получается на самом деле. я ни разу не удивлён, что ты считаешь девелоперов гоцэцэ нормальными. > А вот си переживет и тебя, и меня. и что? кобол ещё жив, фортран ещё жив. мало ли ерунды никак помереть не может. уродец x86 вон, например (и нет, x86_64 лучше не сделал).
	Ответить | Правка | Наверх | Cообщить модератору

	380. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (380), 04-Дек-24, 10:00
	> ух ты, это у нас теперь часть языка. эвона как. Прикинь, часть стандарта на ЯП! STANDARDS        fprintf(), printf(), sprintf(), snprintf(), vprintf(), vfprintf(), vsprintf(), vsnprintf(): POSIX.1-2001, POSIX.1-2008, C99. Да, в отличие от тебя я стандарты еще и читаю. И могу зацитировать ман, как видишь. Режим freestanding конечно начиная с C99 тоже регламентирован, но это несколько другое. Некий subset вон того, как раз без стдлибы. И конечно как обычно - сделав 90% идеи нормально, остадьльные 10% все профачили. Ибо смысл в этой штуке без возможности объект в конкретную секцию разместить или скажем устаканивания "линкер-скриптов"? > как это? ты же выше сам сказал, что это часть языка. Это у кого-то каша в голове: POSIX != C99. А то что printf conforms to сразу обеим... ну да, и чего, так можно было. > бывает, чо. «все побежали — и я побежал.» дополнительный штрих к твоему > неумению оценивать технологии самостоятельно, а не по чужим мнениям. Я как раз имел дело с разными процами, куда лучше x86 уродцев. И имел возможность сравнить и составить мнение, что я думаю о уродце с полутора регистрами, коде состоящем из push и pop чуть менее чем полностью, невозможности делать position-independent code нормально и тому подобным "прелестям". Где даже сначала non-exec регионы было оформить - не того. >> Я вообще не понимаю нужду шарахаться по struct "raw" доступом. > потому что ты в жизни ни одного серьёзного компилятора не написал. Я и правда не испытываю острого желания писать компиляторы. Это не является сферой моих интересов. И все же если кто зачем-то шарахается по struct лобовым доступом я буду считать что он скорее всего делает что-то не так. Ибо struct юзают для структурированного доступа. Если хотелось не это - окей, а массивы вам не катили, надо было через ж...у в левый глаз? > его знает, зачем ты попытался зарубиться со мной на теме компиляторов, > ничего в этом не понимая. Не на теме компиляторов а на теме делания странных вещей с struct'ами. > я ни разу не удивлён, что ты считаешь девелоперов гоцэцэ нормальными. В целом - они более-менее соответствуют моим ожиданиям. Хоть порой и делают странные вещи, см Торвальдс VS null. >> А вот си переживет и тебя, и меня. > и что? кобол ещё жив, фортран ещё жив. мало ли ерунды никак > помереть не может. Ну вот софта на коболе у меня нет, а единственное что на фортране меня колыхало так это xnec2c который - внезапно - перепевка ЭТОГО на си, чем и интересно :)
	Ответить | Правка | Наверх | Cообщить модератору

	382. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 04-Дек-24, 10:13
	> Прикинь, часть стандарта на ЯП! ты мне сейчас серьёзно цитируешь маны как authoritative source по стандартам? no, really? >> как это? ты же выше сам сказал, что это часть языка. > Это у кого-то каша в голове: POSIX != C99. А то что > printf conforms to сразу обеим... ну да, и чего, так можно > было. здесь играем, здесь не играем, здесь рыбу заворачивали. >> его знает, зачем ты попытался зарубиться со мной на теме компиляторов, >> ничего в этом не понимая. > Не на теме компиляторов а на теме делания странных вещей с struct'ами. при этом тема, откуда это началось, была про ABI, и про реализацию внутри компилятора. ты так троллировать пытаешься, или у тебя просто настолько рассеяное внимание, что удержать контекст обсуждения оно не может, и тебе приходится переизобретать его на ходу? >> я ни разу не удивлён, что ты считаешь девелоперов гоцэцэ нормальными. > В целом - они более-менее соответствуют моим ожиданиям. да я же говорю, что не удивляюсь. вы же часть одного и того же — большой беды современного ойте. >>> А вот си переживет и тебя, и меня. >> и что? кобол ещё жив, фортран ещё жив. мало ли ерунды никак >> помереть не может. > Ну вот софта на коболе у меня нет, а единственное что на > фортране меня колыхало так это xnec2c который - внезапно - перепевка > ЭТОГО на си, чем и интересно :) о, снова пошла песня: «я не видел — значит, не существует». скучно, право.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Бывалый Смузихлёб (ok), 24-Ноя-24, 08:57
	Зато, как славно показали себя иные адепты строгой и явной типизации и отсутствия такого у того же ЖС вот то ли дело сишечка Стоило лишь в некоторые ЯП подвезти auto. Наворачивали за обе щёки и обмазывали вообще всё до чего могли дотянуться, а не использовали ранее - тупо потому что такой возможности не было
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	162. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от ProfessorNavigator (ok), 24-Ноя-24, 12:51
	В С++ auto есть уже достаточно давно, и да, может вызывать проблемы. В том числе с читаемостью кода. Но есть у него и плюсы. Когда у вас std::find_if возвращает например итератор вида std::vector<std::tuple<MyClassOne, MyClassTwo, std::shared_ptr<MyClassThree>>>::iterator, то проще написать auto it = std::find_if(...). В данном случае и так сразу видно, итератор чего вернётся, и понятно - каким он будет. Поэтому auto вполне уместно - от него читаемость кода только повысится. Но злоупотреблять им естественно не стоит. Иначе, как вы правильно заметили, потом просто запутаетесь, какая функция что возвращает, и будете ловить проблемы на ровном месте.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	235. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (166), 24-Ноя-24, 18:45
	Не позволяйте автомату (компилятору) определять ваш код за вас. Кроме того есть версии библиотек.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	242. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 24-Ноя-24, 19:47
	> зачем вообще такое добавлять в язык со сторой типизацией? Это называется автовывод. Советую посмотреть на ML.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	253. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от nobody12 (?), 25-Ноя-24, 10:31
	Увы, если для С++ это имеет смысл, чтобы не писать типы из 100500 шаблонов (привет Boost), то для обычного С это действительно вредительство
	Ответить | Правка | Наверх | Cообщить модератору

	269. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (244), 25-Ноя-24, 14:19
	> чтобы не писать типы из 100500 шаблонов А в сях 100500 макросов. > то для обычного С это действительно вредительство Ядро линукса, поиск гитхаба, ищем где используют кривые аналоги auto. typeof(x) - 55 файлов. __typeof__(x) - 13 файлов. __auto_type - 9 файлов. typeof(var) ... = ... var - до 1000 файлов (backreference в поиске не работает) Начни с главного вредителя, Торвальдса.
	Ответить | Правка | Наверх | Cообщить модератору

	309. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 21:25
	> Ядро линукса, поиск гитхаба, ищем где используют кривые аналоги auto. > typeof(x) - 55 файлов. > __typeof__(x) - 13 файлов. > __auto_type - 9 файлов. > typeof(var) ... = ... var - до 1000 файлов (backreference в поиске > не работает) typeof(var) это мягко говоря не синоним auto и может использоваться чертовой кучей иных способов. > Начни с главного вредителя, Торвальдса. Да, начните. Сделайте свой проект, дайте этому негодяю мастеркласс. Что, слабо? А сколько пафосу было...
	Ответить | Правка | Наверх | Cообщить модератору

	316. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 26-Ноя-24, 08:15
	>> typeof(var) ... = ... var - до 1000 файлов > typeof(var) это мягко говоря не синоним auto и может использоваться чертовой кучей > иных способов. А буквой t ещё древние римляне пользовались. Я ведь полную конструкцию привёл, не надо её обрезать. > Да, начните. Сделайте свой проект, дайте этому негодяю мастеркласс. - ананасы в пицце (вывод типов в C) - это вредительство - пиццерия на букву G давным-давно добавила, а в неё ходит коллектив L - займитесь ими! - ??? Это вы здесь вредительство искали. Или уже вредительство уже не вредительство, когда оказалось, что его Линус одобрил?
	Ответить | Правка | Наверх | Cообщить модератору

77. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
Сообщение от Аноним (77), 24-Ноя-24, 05:35
Зачем снова новый тип char8_t, если уже есть char и unsigned char. Более того есть еще stdint.h где есть int8_t и uint8_t. Почему?
Ответить | Правка | Наверх | Cообщить модератору

	85. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Neon (??), 24-Ноя-24, 05:44
	Почему "Ы" ???  Чтоб никто не догадался!)
	Ответить | Правка | Наверх | Cообщить модератору

	140. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 11:24
	Почему? А потому что диды-недостандартописаки смогли подоcpaть даже в такой простой вещий как char. Вот ответь на простой вопрос - обычный char будет знаковым или беззнаковым? А вот хз, как повезет. Для gcc он по умолчанию signed, но если использовать флаг -funsigned-char, то будет unsigned. Но опять же не везде - для Android NDK он по умолчанию unsigned и если что нужно юзать -fsigned-char. А для MSVC он по умолчанию signed, но флаг нужно использовать другой. При этом char8_t определен однозначно: "char8_t is an unsigned integer type used for UTF-8 and is the same type as unsigned char." en.cppreference.com/w/c/string/multibyte/char8_t
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	155. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 12:29
	Диды писали для себя и не думали о глобализации. Еще они дали местным инженерам адаптировать для своей аппаратной платформы.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 17:03
	Японцы с тобой несогласны вся Азия приветствует Юникод.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 12:27
	Потому что стандартом символа стал уникод. Кроме того это унификация под типы фиксированной ширины.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	182. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 14:54
	Давайте проведем эксперимент в Debian vi test.c #include <stdio.h> int main(int argc, const char *argv[]) {     printf("%s\n", argv[1]);     return 0; } make test ./test Привет! Привет! Вопрос: Что я делаю не так ?
	Ответить | Правка | Наверх | Cообщить модератору

	199. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:28
	> make test > ./test Привет! > Привет! > Вопрос: Что я делаю не так ? Ну, для начала - не проверяешь что argv[1] вообще был, хотя-бы :). Так что если это запустить без аргументов... :)
	Ответить | Правка | Наверх | Cообщить модератору

	208. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 16:48
	Не проверяю для краткости. Вопрос не об этом. "Привет!" - это UTF-8 строка, а в main char** .
	Ответить | Правка | Наверх | Cообщить модератору

	284. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от _kp (ok), 25-Ноя-24, 16:14
	>>UTF-8 строка, а в main char Так Вы со строкой ничего и не делаете, а выводите что дали. Длина и то, по завершающему нулю. А вот если, например, посимвольно будете выводить, или посчитать длину..
	Ответить | Правка | Наверх | Cообщить модератору

	373. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 06:17
	> Так Вы со строкой ничего и не делаете, а выводите что дали. > Длина и то, по завершающему нулю. > А вот если, например, посимвольно будете выводить, или посчитать длину.. А вы вообще знаете как правильно считать посимвольно какие-нибудь иероглифы, всякие там модификаторы, RTL/LTR и тому подобные приколы? Unicode в этом смысле - тот еще брейнфак получился. А вот смайликов не хотели? А еще и цветных, а?!
	Ответить | Правка | Наверх | Cообщить модератору

	216. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 17:00
	./test Привет! > hello.txt hexdump -C hello.txt 00000000  d0 9f d1 80 d0 b8 d0 b2  d0 b5 d1 82 21 0a        |............!.|
	Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

	229. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 18:12
	Про это и говорю. Вы прозрачно работаете с char не подозревая о его ширине. Когда-то она была равна 8 битам.
	Ответить | Правка | Наверх | Cообщить модератору

	255. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (6), 25-Ноя-24, 11:14
	Это не прозрачно. Printf %s просто выводит байты и эмулятор терминала пытается их интерпретировать (по случайному совпадению он настроен на utf-8). Если ты попробуешь работать с текстом посимвольно, быстро осознаешь, что тут не так. При этом wchar обычно для utf-16, но там тоже не каждые 16 бит что-то означают. Одно из заметных следствий из этого состоит в том, что файловое имя в 64 символа не поместится в 255 байтное ограничение для имён файлов. И нельзя навскидку сказать, сколько символов можно будет записать -- это может быть и 64 и 255 и сколько угодно между этими значениями.
	Ответить | Правка | Наверх | Cообщить модератору

	271. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (271), 25-Ноя-24, 14:36
	> Так что если это запустить без аргументов... :) Думаю, Вы привели неудачный аргумент. Всегда нужно знать, какие аргументы передать в функцию, и какие функция ожидает. Можно, конечно, в функции сделать обработку неправильных аргументов или вообще пустых, но это дополнительно утяжеляет функцию. Помнится, была (может, и сейчас есть) великобританская библиотека что-то типа Applied Statistics. Там каждая функция стандартно анализировала все эти вещи, включая неправильные значения переданных параметров. Считаю это излишним. Очистку и контроль данных лучше делать до вызова алгоритма их обработки, не увеличивая объем кода в 2-3 раза.
	Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

	310. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 21:27
	>> Так что если это запустить без аргументов... :) > Думаю, Вы привели неудачный аргумент. Всегда нужно знать, какие аргументы передать в > функцию, и какие функция ожидает. В данном случае достаточно запустить прогу без аргументов и она радостно брякнется, референснув argv[1] которого там даже в проекте нет :)
	Ответить | Правка | Наверх | Cообщить модератору

	259. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (259), 25-Ноя-24, 11:51
	Вот сразу видно счастливого человека! Ни разу не е*ался с длинами символов и кодировками)
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	265. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (237), 25-Ноя-24, 12:19
	А потом начинается диакретика. А потом какие-нибудь арабские языки… и идёшь вешаться.
	Ответить | Правка | Наверх | Cообщить модератору

	280. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 16:05
	Цитата из Википедии. >Стандарт Юникод поддерживает письменности языков как с направлением написания слева направо (англ. left-to-right, LTR), так и с написанием справа налево (англ. right-to-left, RTL) — например, арабское и еврейское письмо. В обоих случаях символы хранятся в «естественном» порядке; их отображение с учётом нужного направления письма обеспечивается приложением. Блин это так сложно (сарказм). Иди вешайся, лично я пас.
	Ответить | Правка | Наверх | Cообщить модератору

	273. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (271), 25-Ноя-24, 14:43
	> Ни разу не е*ался с длинами символов и кодировками) Ага, особенно для языков с написанием справа налево и с иероглифическим письмом. Поэтому маленький пример приведу. В естественно-научных дисциплинах 99% мировых публикаций выходит на английском языке. По крайней мере в этой области есть ли смысл вообще переводить ПО на локальные языки? Для себя решил, что ради 1% тратить кучу времени на локализацию и интернационализацию в ущерб смысловой начинке проекта - нет. В новом проекте избавляемся от переводов и кодировок в принципе - там нет ни одной буквы на не-латинице.
	Ответить | Правка | К родителю #259 | Наверх | Cообщить модератору

	282. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 16:09
	>По крайней мере в этой области есть ли смысл вообще переводить ПО на локальные языки? Внутри пещеры. смысла нет. >Для себя решил, что ради 1% ... Рад за тебя. Хоть что-то сам решаешь. >В новом проекте избавляемся от переводов и кодировок в принципе - там нет ни одной буквы на не-латинице Не понял логический смысл этого предложения.
	Ответить | Правка | Наверх | Cообщить модератору

	286. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 16:21
	> В естественно-научных дисциплинах 99% мировых публикаций выходит на английском языке. > В новом проекте избавляемся от переводов и кодировок в принципе - там нет ни одной буквы на не-латинице. А потом твой пользователь пытается сохранить файл с путем или именем и... приложение падает? Думаю это плохой опыт для пользователя) Я уже молчу что япония, корея, израиль - это весьма развитые страны страны отличной научной базой. И китай, кстати, тоже.
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

87. "GCC 15 будет использовать стандарт C23 по умолчанию"	–3 +/–
Сообщение от Аноним (87), 24-Ноя-24, 05:50
> Удалена возможность определения функций в стиле K&R C, используемом до принятия спецификации ANSI C и описанном в книге "The C Programming Language" Кернигана и Ритчи. Так это уже не тот язык С, который придумали его изобретатели Брайан Керниган и Деннис Ритчи. Это совсем совсем другой язык "С23" и т.д. и т.п. А значит, можно использовать старый стандарт 89 года, с оговоркой, что это настоящий язык С.
Ответить | Правка | Наверх | Cообщить модератору

	136. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 24-Ноя-24, 10:42
	> старый стандарт 89 года Так это тоже "уже не тот язык С" - в K&R C не было UB (поэтому переиздание книжки K&R устарело примерно в момент выхода).
	Ответить | Правка | Наверх | Cообщить модератору

	178. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 14:38
	Это не важно.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 24-Ноя-24, 16:29
	Не важно что? Пропасть между K&R C и C89 важна. "Переносимый ассемблер" поднялся выше, стал языком со сложными оптимизациями и лишился части старых низкоуровневых возможностей. Ритчи о будущем стандарте в 1988 высказался вот так. Вырываю из контекста, но слова с тех пор выстрелили по-всякому*. aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs The fundamental problem is that it is not possible to write real programs using the X3J11 definition of C. The committee has created an unreal language that no one can or will actually use. https://arxiv.org/pdf/2201.07845 --> https://groups.google.com/g/comp.lang.c/c/K0Cz2s9il3E/m/YDyo... * - -fwrapv и -fno-strict-aliasing в Linux как отступление от стандарта / "туалетной бумажки" / "bogus shit". - "Наличие UB - это лицензия компилятору на выкидывание кода, а не повод указать на ошибку". - Миф, что "-O3/-Ofast - опасные оптимизации" или иначе говоря реальность, в которой "в коде на C(++) разбросан опасный UB, который выстрелит при включении законных оптимизаций".
	Ответить | Правка | Наверх | Cообщить модератору

	209. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 16:50
	> Пропасть между K&R C и C89 важна. По сравнению с тем, что K&R и С23 это разные миры.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 24-Ноя-24, 17:48
	Тогда выходит, что и C89 & С23 - разные миры. Это такая же ерунда, как про Кернигана, Ритчи и "их" C89. Парадигма языка менялась только в C89. C23 добавляет memset_explicit, не потому что он такой весь новый, а чтобы решить проблему, созданную в C89.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 17:21
	В 1988 году я ещё играл в "Лунолёт" на МК-61 и таких подробностей про С89 не знал. Я говорю "условно", чтобы принять ранний стандарт за эталон, так как он реализован в GCC. Оставлю опции компилятору. Но буду за этим следить тоже.
	Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

	300. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 18:45
	>В 1988 году я ещё играл в "Лунолёт" на МК-61 и таких подробностей про С89 не знал. В 1988 у нас кроме чёрно-белого телевизора ничего не было. На цветной телевизор денег не хватало. Ты видимо сынок богатого зажравшегося политработника.
	Ответить | Правка | Наверх | Cообщить модератору

	319. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (264), 26-Ноя-24, 12:19
	Да ладно вам, MK-61 и МК-52 рядовым студентам покупали обычные родители.
	Ответить | Правка | Наверх | Cообщить модератору

	320. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 26-Ноя-24, 12:21
	> Да ладно вам, MK-61 и МК-52 рядовым студентам покупали обычные родители. 52 стоил рублей 100. Это не так уж мало. А 61, кажется был еще дороже.
	Ответить | Правка | Наверх | Cообщить модератору

	325. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (264), 26-Ноя-24, 14:09
	MK-52 навороченнее. У него были разъёмы для подключения модулей расширения. Поэтому, вряд-ли 61 дороже.
	Ответить | Правка | Наверх | Cообщить модератору

	332. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 26-Ноя-24, 17:31
	Говоришь так, как будто было изобилие. Дефицит был. Эти МК-52 только в обласных центрах и столице продавали, вернее нет, их доставали. Сейчас скажи, что в Артеке мог отдохнуть рядовой советский ребёнок, хотя путёвка стоила "вряд-ли дороже" да?
	Ответить | Правка | Наверх | Cообщить модератору

	368. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Anonymmm (?), 29-Ноя-24, 23:40
	У меня на МК-61 написано 85 рублей. Без проблем покупался даже студентами (чуть больше стипендии).
	Ответить | Правка | Наверх | Cообщить модератору

	346. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Соль земли (?), 27-Ноя-24, 09:50
	int no_args() дайте две.
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	238. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 18:52
	Опции GCC, управляющие диалектом языка. https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	294. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Bottle (?), 25-Ноя-24, 17:31
	Я тебе скажу, о! ужас!, суровую правду жизни: ты и на русском языке говоришь не эпохи Рюрика, а на языке Пушкина, Толстого, Достоевского. Да, Сишка не может кристализироваться и быть идеальной. Ей нужно развитие.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

88. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
Сообщение от Аноним (87), 24-Ноя-24, 05:53
Оригинальный язык С описан в книге "The C Programming Language" Кернигана и Ритчи. Все остальное я могу с полным правом игнорировать. Отныне все мои проекты будут базироваться исключительно на книге "The C Programming Language".
Ответить | Правка | Наверх | Cообщить модератору

	157. "GCC 15 будет использовать стандарт C23 по умолчанию"	+3 +/–
	Сообщение от Аноним (166), 24-Ноя-24, 12:34
	Главное держитесь подальше от учеников.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 17:33
	Грамматику языка С я реализую по этой книге. Что не будет сюда подходить, то отнесу на счет дополнительных правил. Можно сказать, что это будет новая ветка развития С, с того момента.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (167), 24-Ноя-24, 13:40
	И обязательно в самом оригинальном vi !
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	177. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 14:36
	Я использую vim - подсветка синтаксиса, авто-дополнение, многооконность в консоли, форматирование, замена и поиск regex, вставка результатов команды. Например, я могу вставить в текст прямо из сайта, не выходя из vim.
	Ответить | Правка | Наверх | Cообщить модератору

	267. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Аноним (264), 25-Ноя-24, 12:34
	Но это уже не TrueЪ. Надо пользоваться тем, что был во времена K&R.
	Ответить | Правка | Наверх | Cообщить модератору

	215. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:59
	Скажи почему ты такой немодный? Модные и молодёжные будут использовать C23!
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

89. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
Сообщение от Аноним (87), 24-Ноя-24, 06:01
> указания имён неиспользуемых параметров при определении функций (как в C++) > определения атрибутов как в С++ Также языком С++ лично я считаю язык представленный в книге The C++ Programming Language (1st edition). Все остальное - это выдумки, и я могу их с полным правом игнорировать.
Ответить | Правка | Наверх | Cообщить модератору

	117. "GCC 15 будет использовать стандарт C23 по умолчанию"	+3 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 09:17
	Требую больше постов о том, как ты игнорируешь. Я большой любитель поведения людей, которое можно описать словами "я такая противоречивая сегодня".
	Ответить | Правка | Наверх | Cообщить модератору

	240. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 18:57
	Это какой-то патентный троллинг.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

92. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от ijuij (?), 24-Ноя-24, 06:35
> Удалена возможность определения функций в стиле K&R C Это меня огорчает, у меня есть ещё код в подобном стиле!
Ответить | Правка | Наверх | Cообщить модератору

	93. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от ijuij (?), 24-Ноя-24, 06:46
	А так мне все нововведения нравятся, и особенно хочу отметить это: > Добавлены типы "_BitInt (N)" и "unsigned _BitInt (N))" для определения целых чисел с указанным числом битов 🔝
	Ответить | Правка | Наверх | Cообщить модератору

	101. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (101), 24-Ноя-24, 07:47
	Мммм. Как же мне не хватало переменных длиной 3, 7, 11 бит
	Ответить | Правка | Наверх | Cообщить модератору

	202. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:31
	> Мммм. Как же мне не хватало переменных длиной 3, 7, 11 бит Вообще иногда удобно. Если мне нужен диапазон 0..7 и при этом алго корректно работает, отдельно кодить валидацию и что вообще делать если на вход дали 20 ибо даже с uint8_t так можно было - сами понимаете. Хотя конечно если очень сильно хотелось - можно было битовыми полями в struct это организовать, но у struct'ов есть свои скелеты в шкафу. Главный из которых - если мы полтора параметра хотели, разворачивать огород с typedef struct было несколько не с руки.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (109), 24-Ноя-24, 08:53
	Это ж какой простор для UB! Ну и вообще, полностью идёт вразрез с идеей сишки. Всякие char/int реализуются аппаратно by design, а это-то как?
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	114. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от ijuij (?), 24-Ноя-24, 09:00
	> а это-то как? Там внедрено много кода, взгляни на коммиты в GCC: https://github.com/search?q=repo%3Agcc-mirror%2Fgc...
	Ответить | Правка | Наверх | Cообщить модератору

	142. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Советский инженер (ok), 24-Ноя-24, 11:29
	> Ну и вообще, полностью идёт вразрез с идеей сишки. т.е. когда поле структуры 3,7,11 бит - это не идет в разрез, а вот когда это отдельная переменная - то уже идет? так по твоему?
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	158. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (166), 24-Ноя-24, 12:41
	Есть масочная операция над регистром и есть ячейка памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (244), 24-Ноя-24, 12:48
	Но это не ответ на вопрос о bitfield'ах.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (244), 24-Ноя-24, 18:53
	> вопрос о Так, я не антисемит, если что. (вчера) C++ Standards Contributor Expelled For 'The Undefined Behavior Question' https://slashdot.org/submission/17330375/c-standards-contrib...
	Ответить | Правка | Наверх | Cообщить модератору

	248. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (248), 25-Ноя-24, 08:48
	>https://slashdot.org/submission/17330375/c-standards-contrib... >In response to requests to change the title, Mr. Tomazos declined, stating that "We cannot allow such an important word as 'question' to become a form of hate speech." He argued that the term was used in its plain, technical sense and had no connection to the historical context cited by critics. >Following this decision, Mr. Tomazos was expelled from the Standard C++ Foundation, and his membership in the ISO WG21 C++ Standards Committee was revoked. О, теперь слово "Question" оказывается нельзя применять. Когда уже запретят пить воду потому что Гитлер тоже её пил?
	Ответить | Правка | Наверх | Cообщить модератору

	204. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:34
	> Есть масочная операция над регистром и есть ячейка памяти. А в чем проблема чтобы расширить битовые поля чтобы они не были только в struct? Ну или почему как member struct'а так можно - а по отдельности ни ни? Вы же понимаете что когда мы хотели это - мы таки заводили struct? Просто печатать было больше. И только.
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

	230. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 18:21
	struct это сущность Битовое поле это дополнительная операция над сущностью. Биты не хранятся.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 19:45
	Так можно сказать что и байты не хранятся, потому что компиляторы выравнивают размер структуры на значение кратное 8, а некоторые платформы не позволяют адресовать произвольные байты, все адреса должны иметь сколько-там двоичных нулей в хвосте. Но ведь то же самое с битами, отдельные биты не адресуются, потому что адреса обрезаются до байт или до чего-то большего. И компиляторы, храня биты, выравнивают их размер до кратности байту. При этом они ленятся упаковывать структуры действительно плотно, и если перемежать байты с битами, то байты не будут начинаться с дробного адреса.
	Ответить | Правка | Наверх | Cообщить модератору

	287. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от _kp (ok), 25-Ноя-24, 16:25
	>>Битовое поле это дополнительная операция над сущностью. >>Биты не хранятся. Смотря на каких аппаратных архитектурах. Где то и косвенно адресуемые биты есть. А вот что бы описать поля структуры с битовыми полями разного размера в байтах, что бы не распаковывать/запаковывать их, а использовать как есть, сейчас приходится обмазывать исходник батареями union'ов. Что излишняя работа, и хуже читать. Или по старинке наклепать портянки дедовских масок для разных комбинаций битов. В первом случае удобнее использовать, во втором попроще написать, но исходник далее будет толще и менее читаемый. Все.
	Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

	311. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 21:32
	> struct это сущность > Битовое поле это дополнительная операция над сущностью. > Биты не хранятся. И тут стоит сказать что таки да - вон то вызывает чаще всего не особо эффективный RMW на этом всем. Так что код воображения не поражает. Зато если у меня скажем есть enum с 4 состоянияи и я поле в struct сделал :2 и все 4 корректно рюхаются internals - потуги скормить что-то откровенно левое в функцию желавшую в "поле апи" нечто в интервале 0..3 станет - мягко говоря - довольно нетривиальным занянием. Это при случае - свалит компил, ибо запросто будет как минимум жырный варнинг про невозможность represent вон то в вот этом. Чем спасет от какого-нибудь жирного бага в рантайме, в фирмвари, где-то уже сильно опосля.
	Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

	159. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (166), 24-Ноя-24, 12:44
	Это изначально было неудобно и было вкусовщиной.
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

153. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
Сообщение от Аноним (153), 24-Ноя-24, 12:26
Успехов GCC конечно, но лучше я буду использовать odin-lang и даже zig-lang уже сейчас.
Ответить | Правка | Наверх | Cообщить модератору

	304. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (304), 25-Ноя-24, 20:33
	А я буду использовать GCC, потому что он есть везде - от Windows до Haiku.
	Ответить | Правка | Наверх | Cообщить модератору

	306. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (153), 25-Ноя-24, 21:13
	Да ты и сбр*шь. Зачем писать под всё подряд, только распылять свои силы.
	Ответить | Правка | Наверх | Cообщить модератору

	321. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (264), 26-Ноя-24, 12:25
	Ну если под Windows понимать Msys2, то там отличий от юзерспейса под Linux немного. Рзве что, только в отношении API сокетов.
	Ответить | Правка | Наверх | Cообщить модератору

156. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (156), 24-Ноя-24, 12:30
... которое теперь приводит к выводу типа при определении объектов, что позволяет использовать признак "auto" вместо типа для определения типа переменных на основе типа выражения для их инициализации типа всё понятно
Ответить | Правка | Наверх | Cообщить модератору

164. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (-), 24-Ноя-24, 13:04
На С++23 я уже видел проекты, а кто-нибудь видел проект на С23?
Ответить | Правка | Наверх | Cообщить модератору

	183. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от ijuij (?), 24-Ноя-24, 14:56
	Пожалуйста, наберитесь терпения! Скоро всё увидите, даже не сомневайтесь! 🌟
	Ответить | Правка | Наверх | Cообщить модератору

	205. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:35
	> На С++23 я уже видел проекты, а кто-нибудь видел проект на С23? Учитывая что он финализировался без году неделю как? Coming soon! :D Я вот уже думаю - не заапгрейдить ли мне тут 1 из болванок для моих фирмварей на это :)
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	214. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:58
	> Учитывая что он финализировался без году неделю как? Coming soon! :D Да. Например https://github.com/stephenberry/glaze. > Requires C++23
	Ответить | Правка | Наверх | Cообщить модератору

	362. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 28-Ноя-24, 19:45
	>> Учитывая что он финализировался без году неделю как? Coming soon! :D > Да. Например https://github.com/stephenberry/glaze. >> Requires C++23 Так мы ж вроде про C23 - которы буквально на днях финализировался только. Так что на самом деле он так то C24 скорее, и тот под конец года :). При чем тут та плюсота? А так жесткие требования к компилеру от либы - вовсе даже и не фича, а гемора пачка.
	Ответить | Правка | Наверх | Cообщить модератору

207. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (-), 24-Ноя-24, 16:46
>GCC 15 будет использовать стандарт C23 по умолчанию Это ещё одно доказательство того, что GCC самый передовой в Мире компилятор.
Ответить | Правка | Наверх | Cообщить модератору

226. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (-), 24-Ноя-24, 17:44
>Добавлена поддержка подстановки "%b" для обработки двоичных значений в семействах функций printf() и scanf(). Раньше чтобы десятичное число вывести в двоичном виде как делали?
Ответить | Правка | Наверх | Cообщить модератору

	234. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (166), 24-Ноя-24, 18:39
	Самостоятельно формировали строку в буфере и выводили через спецификатор %s.
	Ответить | Правка | Наверх | Cообщить модератору

	289. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от _kp (ok), 25-Ноя-24, 17:06
	Часто это уже добавлено в компиляторах для контроллеров. Ничего нового, просто зафиксировали. В том числе gcc, ибо для этого компилятор пересобирать не надо, а всего то мелкая правка в libc.
	Ответить | Правка | Наверх | Cообщить модератору

232. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (166), 24-Ноя-24, 18:30
А есть где нибудь статистика используемых ассемблерных инструкций тем или иным компилятором?
Ответить | Правка | Наверх | Cообщить модератору

243. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
Сообщение от Аноним (304), 24-Ноя-24, 20:53
> Стиль K&R подразумевает описание типов аргументов после определения функции, например, "int add(a, b) int a, b; {}" Что это было?
Ответить | Правка | Наверх | Cообщить модератору

	247. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от fuggy (ok), 25-Ноя-24, 01:52
	> Функции с пустым списком аргументов теперь обрабатываются как функции, не принимающие аргументы. Вона ещё было. Тоже с каких-то древних годов тащили.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (6), 25-Ноя-24, 11:42
	в плюсах можно писать main() и в си только main(void) -- насколько это хорошая идея судить не возьмусь, но тащить плюсы в си тема не здоровая.
	Ответить | Правка | Наверх | Cообщить модератору

	260. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (237), 25-Ноя-24, 12:12
	Подобные вещи к плюсам вообще отношения не имеют, как раз их назад тащить есть смысл.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (237), 25-Ноя-24, 12:13
	К плюсам именно как к языку, имею в виду.
	Ответить | Правка | Наверх | Cообщить модератору

	270. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (271), 25-Ноя-24, 14:29
	> тащить плюсы в си тема не здоровая Почему нет? Пишу алгоритмы (бэкэнды) фактически на C с использованием удобных, как мне кажется, возможностей C++ (управление памятью и файловый/потоковый ввод-вывод). Конечно, все это без проблем обрабатывается компилятором g++ как C++. Код, и без того сложный, получается лаконичным и легко сопровождаемым. А почти все, что предлагается выше, делает код эстетически некрасивым, даже неприятным. И толку от этого ноль.
	Ответить | Правка | К родителю #256 | Наверх | Cообщить модератору

	276. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (6), 25-Ноя-24, 15:01
	Это глупость. Либо пишешь на си, чтобы не иметь недостатков плюсов, либо на плюсах, если они позволяют генерировать более эффективный код в конкретном случае. При включении плюсов любой код становится заражённым плюсами. Тут и ресурсоёмкость, и раскрутка стека/исключений, и рантаймы, часто утечки на ровном месте и найти их куда сложнее чем в си, и, опять же, стандарт перегружен и нужно его понимать -- легче ошибиться. Наконец, нет ABI (до сих пор) и это прямо боль, так что применения ограничены.
	Ответить | Правка | Наверх | Cообщить модератору

	292. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (264), 25-Ноя-24, 17:20
	И что вам это ABI так жить мешает? Ну перекомпилируете ваш код, если что. Есть же libffi, если к другим языкам надо. И к тому же, большое изменение ABI, помнится, было последний раз при переходе с g++ v3.3 на v3.4.
	Ответить | Правка | Наверх | Cообщить модератору

	295. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (6), 25-Ноя-24, 17:37
	В реальном коде будут бинарные компоненты, да и в целом пересобирать все зависимости при каждом обновлении тулчейна не очень приятно. И часто не вариант, потому что сборка обновлённым компилятором очень часто сломана (отличный пример интеловские либы, в том числе опенсорсные). Ну вот взять wxwidgets -- все проги после смены компилятора разлетаются во все стороны. Такое вот ABI. Или вон взять osl (https://github.com/AcademySoftwareFoundation/OpenShadingLang...) -- требует держать старый тулчейн для себя и всех как либо связанных компонентов годами. И openimageio туда же. Это всё опенсорс (каждый раз приходится пересобирать по десятку связанных пакетов), с проприетарными компонентами всё слишком печально.
	Ответить | Правка | Наверх | Cообщить модератору

	334. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 26-Ноя-24, 17:37
	> И что вам это ABI так жить мешает? Ну перекомпилируете ваш код, > если что. угу. всё бросил и побежал перекомпилировать, как только бравые парни в g++ что-то сломали. ну, я ж программы и библиотеки пишу не для того, чтобы решать практические задачи, а чтобы писать программы и библиотеки. по какой-то странной причине (недосмотр, надеюсь, его скоро исправят) код на си перекомпилировать не надо. с нетерпением жду отмены этой устаревшей концепции.
	Ответить | Правка | К родителю #292 | Наверх | Cообщить модератору

	285. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 25-Ноя-24, 16:17
	Это плохая практика. Большинство людей от этого давно отошли. Пиши либо на чистом Си, либо на плюсах, не смешивай код.
	Ответить | Правка | К родителю #270 | Наверх | Cообщить модератору

	312. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (153), 26-Ноя-24, 01:42
	Всё же ты пишешь на с++, возможно, иногда делая вставки на си.
	Ответить | Правка | К родителю #270 | Наверх | Cообщить модератору

	314. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (271), 26-Ноя-24, 06:41
	Возможно, и так. Но если нужна DLL, наружу всё-равно выглядывает C.
	Ответить | Правка | Наверх | Cообщить модератору

	291. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от _kp (ok), 25-Ноя-24, 17:11
	> в плюсах можно писать main() и в си только main(void) можно и классику - int main[-1];
	Ответить | Правка | К родителю #256 | Наверх | Cообщить модератору

272. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (272), 25-Ноя-24, 14:38
Лучше бы использовали С89 по умолчанию.
Ответить | Правка | Наверх | Cообщить модератору

	279. Скрыто модератором	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 15:17
	Зачем тебе 1989 год? Половина опеннета в то время ещё не родилось.
	Ответить | Правка | Наверх | Cообщить модератору

	302. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (302), 25-Ноя-24, 19:25
	Код, соответстующий C89, гораздо красивее, совместимость выше, его все используют и т. д.
	Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

	322. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (264), 26-Ноя-24, 12:31
	Кто все? Даже в ядре уже объявили C11, в Glibc и подавно был C99, как минимум.
	Ответить | Правка | Наверх | Cообщить модератору

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

	336. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 26-Ноя-24, 17:50
	> Ладно, не все, но свои программы я пишу в соответствии со стандартом C89. Да хоть на Algol-60 пиши, кому тут какое дело?
	Ответить | Правка | Наверх | Cообщить модератору

	350. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от InuYasha (??), 27-Ноя-24, 20:57
	Согласен на 98.
	Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

274. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (271), 25-Ноя-24, 14:47
Представим, что каждые 5 лет обновляется учебник родного языка. Причем заменяется процентов 10 слов и процентов 30 правил. В языках программирования возможно. Может, оставят Кернигана-Ритчи в покое и направят усилия в плодотворное русло?
Ответить | Правка | Наверх | Cообщить модератору

	278. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (272), 25-Ноя-24, 15:13
	Да компиляторы все равно обратную совместимость сохранят, не беспокойся.
	Ответить | Правка | Наверх | Cообщить модератору

	335. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 26-Ноя-24, 17:41
	> Да компиляторы все равно обратную совместимость сохранят, не беспокойся. ага. как gcc13, например, который стал ругаться на `snprintf(buf, sizeof(buf), "…", …)`. вот не нравится ему, что я возвращаемое значение не проверяю. и он яростно ругается на то, что вывод-де усечён может быть. подумаешь, это же всего лишь легитимное применение стандартной функции, мне так и надо. а нет, компилятору видней. `(void)snprintf(…)` его не убеждает заткнуться. ура, бесполезный ворнинг на пустом месте! именно то, о чём я мечтал: ещё одна дурацкая диагностика, которую надо отфильтровывать. что ещё там отфильтруется вместе с ней в будущем — неизвестно. а мне потом присылают репорты: «у тебя ворнинг там, это же вулнерабилити!» и вроде бы человек хорошего желает, но отчего его так хочется матом послать?
	Ответить | Правка | Наверх | Cообщить модератору

	337. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 26-Ноя-24, 17:58
	> ага. как gcc13, например, который стал ругаться на `snprintf(buf, sizeof(buf), "…", > …)`. вот не нравится ему, что я возвращаемое значение не проверяю. Ну ты то известный раздолбай-концептуал, уж прости. Это таки случай когда семеро 1 не ждут, и в целом - это улучшает состояние дел. А ты если такой гениальный и тебе лучше всех виднее как надо - вот и отношайся с отключением варнинга. Или програмь на обероне. Или как там тебе удобно. > и он яростно ругается на то, что вывод-де усечён может быть. > подумаешь, это же всего лишь легитимное применение стандартной функции, мне так > и надо. а нет, компилятору видней. Именно так. All в целом весьма утомили постоянные факапы, грабли с топором на ручке - и все же решено было топор с рукояти грабель - по возможности снимать. Даже если кому-то суперкомбо инструмент и удобен был, пусть лучше это будет проблемой десятка желателей странного чем половины глобуса. Такой инженерно-человеческий tradeoff. > мечтал: ещё одна дурацкая диагностика, которую надо отфильтровывать. что ещё там > отфильтруется вместе с ней в будущем — неизвестно. а мне потом > присылают репорты: «у тебя ворнинг там, это же вулнерабилити!» и вроде > бы человек хорошего желает, но отчего его так хочется матом послать? Потому что ты что-то делаешь явно не так. И это в целом - подход к программизму, угу. Игнорить значения функций которые не void - моветон.
	Ответить | Правка | Наверх | Cообщить модератору

	338. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 26-Ноя-24, 18:11
	> Ну ты то известный раздолбай-концептуал, уж прости. Это таки случай когда семеро > 1 не ждут, и в целом - это улучшает состояние дел. угу. и игнорирование явного указания на то, что я понимаю, что делаю — в виде `(void)snprintf()` — тоже улучшает. слава роботам! > А ты если такой гениальный и тебе лучше всех виднее как > надо - вот и отношайся с отключением варнинга. нет, мне не надо. я вообще перестал обновлять gcc после шестой версии. надо было ещё раньше, конечно. а вот пипол настаивает на сборке новыми гоцэцэ, потому что других в их дистрибутивы не завезли. и потом капает мне в мозг идиотией, место которой — в багтрекере гоцэцэ. в итоге идиоты — там, а зря тратят время — пользователи и я. > Или програмь на обероне. вообще-то в основном так и делаю. ещё и с самописным компилятором. но иногда, по просьбам, так сказать, общественности… и тут оно Как Прыгнет! > Именно так. All в целом весьма утомили постоянные факапы, грабли с топором > на ручке - и все же решено было топор с рукояти > грабель - по возможности снимать. при этом контроль выхода за границы массива — что и является источником подавляющего большинства багов — нет, не будем. а вот по поводу совершенно безопасной `snprintf()`, которая хучь лопни, но больше буфера не запишет — вот тут мы будем кричать. это называется не секурити, это называется snake oil. > Даже если кому-то суперкомбо инструмент и > удобен был, пусть лучше это будет проблемой десятка желателей странного чем > половины глобуса. Такой инженерно-человеческий tradeoff. поясни мне, пожалуйста, почему усечение вывода в `snprintf()` — это опасно, а выход за границы массива — безопасно? а то я старый, никак не пойму. > Потому что ты что-то делаешь явно не так. ага. ищу ключи не под фонарём, а там, где потерял. это сейчас немодно. > Игнорить значения функций которые не void - моветон. и что мне с этим значением делать? поясни, будь добр. я-то использую `snprintf()` именно затем, чтобы он мне больше буфера не записал. никакого другого метода для этого в стандартной библиотеке нет. вот получил я количество записаных символов — и? оно мне совершенно неинтересно. предлагаешь проверять, не больше ли оно буфера, вдруг у меня libc поломаный? ну, тогда у меня явно намного более серьёзные проблемы, чем эта мелочь. а в любых других случаях мне без разницы. итак: где тут страшная ошибка, где тут угроза секурити? уж раз начал — то будь любезен, поясни до конца. я с удовольствием поучусь.
	Ответить | Правка | Наверх | Cообщить модератору

	344. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 27-Ноя-24, 03:09
	> угу. и игнорирование явного указания на то, что я понимаю, что делаю > — в виде `(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.
	Ответить | Правка | Наверх | Cообщить модератору

	345. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 27-Ноя-24, 08:38
	>> угу. и игнорирование явного указания на то, что я понимаю, что делаю >> — в виде `(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. у меня начинает зарождаться подозрение, что если чуть-чуть развить твою логику, то идеальный компилятор — это который отказывается компилировать вообще любой код. ведь программа может делать не то, что задумал программист! опасно. всё-таки сколько тебе надо эквилибристики, лишь бы не признавать, что девелоперы гоцэцэ в очередной раз тупо профакапились и тоже не хотят этого признавать.
	Ответить | Правка | Наверх | Cообщить модератору

	364. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 28-Ноя-24, 20:46
	> …который авторы гоцэцэ багом не считают. к сожалению, соответствующий тикет в их > багтрекере уже не найду: с какого-то момента я перестал сохранять примеры > их идиотии. Лично мне довольно пофиг - я в целом вполне могу жить с 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, а может и еще какой, если вдруг надо.
	Ответить | Правка | Наверх | Cообщить модератору

	365. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 28-Ноя-24, 22:00
	> Лично мне довольно пофиг - я в целом вполне могу жить с > 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 - тоже. И теперь стандарты кодинга стали жестче. а программирования — остались какими были. > Раздолбаить стало непочетно. пчёлы против мёда. > Расчистка барахла по площадям. ой, а кто же там намусорил-то? >> почему повышение количества мусорных ворнингов понижает желание включать ворнинги и >> вчитываться в них в принципе? > К счастью это выступает надежным детектором отношения и чьим именно софтом пользоваться > не надо. Так что я видя такие полися могу быстро сделать > информированный выбор что мне с таким проектом и его отношением к > качеству кода не по пути. ну да. судя по твоему описанию твоих практик — я бы, скорее всего, твои патчи не принял. так что ты, в принципе, прав. ;-) > Если полпланеты землю копытом роет, вероятно …проект, наконец, дозрел. > де факто ты первая тушка с такой претензией на моем пути. потому что большинство людей или молча жрут то, что им скармливают авторы гоцэцэ (ты тут уже который пост мне доказываешь, что надо жрать и благодарить за тёплую шапку), или — меньшинство — уже имели опыт взаимодействия с гоцэцэ-дивилаперами, и больше не хотят. это самое меньшинство, кстати — обычно совпадает с множеством людей, которые действительно понимают в том числе и внутреннюю механику, и не боятся компиляторов, кодогенов и асмов. > Т.е. масштаб эффекта для меня выглядит - мизерным. А улучшени фич > статического анализа и проч я очень одобряю. Это позволяет делать мне > более качественный в целом код. гуанокод. > Багов бояться - софт не девелопать. продолжение квинтэссэнции современного «девелопинга».
	Ответить | Правка | Наверх | Cообщить модератору

	375. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 03-Дек-24, 18:41
	>> мир не идеален, и делать из этого трагедию вселенского масштаба я не собираюсь. > ну, кто-то молча хавает что дали, а кто-то не хочет. И из трезвых рациональных предложений лучше чем это, будет, например, что? Извини, маргинальные вещи меня не интересуют - ибо переписывать весь софт на планете в мои планы не входит. Это 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 по скорости и размеру кода. А простой кодоген, увы, не сможет в многие оптимзации и код будет хуже. >> Багов бояться - софт не девелопать. > продолжение квинтэссэнции современного «девелопинга». Увы, мир становится сложнее - и не идеален - поэтому приходится придумывать энные вещи балансирующие трудносочетаемые желания. Да, я совсем не хочу пасквиль галимый с неотключаемыми рантайм проверками математики как системный ЯП.
	Ответить | Правка | Наверх | Cообщить модератору

	376. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 04-Дек-24, 00:02
	>>> мир не идеален, и делать из этого трагедию вселенского масштаба я не собираюсь. >> ну, кто-то молча хавает что дали, а кто-то не хочет. > И из трезвых рациональных предложений лучше чем это, будет, например, что? не хавать. я вот стараюсь. > окей, покажи как ты лихо девелопаешь печатки > на уровне хотя-бы не хуже KiCad? без проблем. но поскольку это надо не мне, а тебе — какова оплата? заинтересуй меня — и я покажу. > Встречный вопрос: как так получается, когда я прошу показать мне конкретные проблемы > от CRC32 как функции хеширования в btrfs, для меня, в сценариях > практикуемых мной, я не получаю ничего кроме столь же общих бла-бла? > Видишь, кэп, в эту игру могут играть и двое. нет. это разные игры. я прошу показать мне недавние объяснения, про которые говорят, что они были, но отчего-то их прячут. ты просишь в очередной раз пояснить тебе, почему земля не плоская. > За тобой ровно такой же failure mode тоже водится. как и много других, разве ж я с этим спорю? стараюсь избегать, получается не всегда, увы. > В этом мире засчитываются - решения которые есть и работают. а что иногда рентгеновский аппарат пациентов убивает, шатлы и самолёты падают… да ерунда, хумансов на планете много, подумаешь. time-to-market важнее. >>> и просто оценить ожидаемое поведение алго. >> не можешь. ты не понимаешь, как он работает — ровно это ты выше сам написал. > Вообще-то когда меня интересует - я и более-менее понимаю, и наконец - > могу просто померять типовые ворклоады. И отправить теоретиков в пень. вот тут даже и комментировать дополнительно не надо: это только испортит всю прелесть. >> мой рафинированый академичный мозг применялся в том числе и для написания софта >> для контроллеров. ещё во времена восьмибиточек. да и софт, работающий на >> ядрёных станциях, я знаю не по наслышке. > Мне все равно. Я делаю несколько более приземленные управляюшие штуки. я как-то перестал вообще понимать, что ты делаешь. за что ни возьмись — всё не то оказывается. > А програминг софта для АЭС в мои планы - таки - не > входит. в мои тоже не входил. так получилось. джентльмен в поисках десятки, так сказать. тяжёлые жизненные условия заставили. потом условия стали получше, и я ушёл. >> ну, живите, кто ж запрещает. меня просто умиляет нежелание видеть ничего другого. >> забавно палочкой потыкать. > Тыкать палочкой имеет смысл если ты мог предъявить что-то лучше. Но с > этим не судьба. у меня есть получше. то, что ты этого не видел, а описания тебе не нравятся… ну, что ж поделать. я сделал лучше, я доволен, я тыкаю палочкой. вот один из немногих закрытых проектов — это мой компилятор, да. меня немножко залолбали вскваки «нинужна» от мимокрокодилов, и кисо абиделос. > Или где например ФС лучше от тебя после > наездов на btrfs? все лучше. именно поэтому я в своих кастомных штуках использовал именно их, а не бтр. если бы было иначе — использовал бы бтр. осчастливливать же мир — как я неоднократно писал — в мои планы давно не входит. > Не, такая штука в 1 фэйс до ума > не доводится, как максимум лабораторный макет получится. оверинжинирнутый хлам никогда в одну морду не пилится. именно поэтому он оверинжинирнутый хлам. > Было бы круто если правда. Но я бы не удивился узнав что > ты отлепляешь зад и идешь к выключателю хихи. так и есть. ну, не считая сортира, где свет включается и выключается сам. включается по движению, выключается по таймеру — а чтобы не засиживался, задумавшись, ага. ;-) > смотришь на градусник за бортом сам ваще не смотрю, даже не имею такого. это изобретение цивилизации прошло мимо меня. смотрю, во что пипл одет — хватает. > И если так, боюсь, подтверждает идею "детектора паттернов" > - сапожника без сапог. я, вообще-то, «системый программист» (глупый термин, но пусть будет) и компиляторщик, а не разработчик дивайсов «полным циклом». я умею, но мне это занятие не нравится. не штырит. не то чтобы оно плохое — но не штырит. как тебя не штырит компиляторы делать. > Не пытайся меня обмануть я вообще не лгу. коммунистическая этика запрещает, однако. > Спасибо кэп. Но vulnerability только в определенных случаях. Но вот за такое > я дидов и не жалую. вообще-то у дидов это не было UB. а потом пришли стандартизаторы — и всё сразу стало плохо. >>> Теперь и ты понимаешь что такое "валидация тулчейна". >> я только не понимаю, почему это должны делать конечные пользователи, натыкась на >> баг, который вообще не должен был прожить дольше максимум одного коммита. >> хотя там, наверное, тоже не могут свои алгоритмы доказать… > Ну вот нету там гениев типа тебя, они и играют как умеют. сами виноваты, чо. > А сапожники отвисают без сапог, ничего нового. в данном случае я как раз с сапогами. потому что критическая масса таки накопилась, и с воплем: «довольно это терпеть!» я таки сделал себе свой тулчейн. >> это их личные проблемы. > Хочешь сказать что с тобой так не бывает? а с чего бы мне не иметь плана на случай, когда основной не подойдёт? я уже говорил, что по необходимости и на сишечке пишу, и библиотеки сторонние использую. что могу — делаю сам. что не могу (или в конкретных обстоятельствах очень жмёт что-то другое) — не делаю, беру что есть. >> «как есть гуано чтобы не очень заляпаться», руководство. спасибо, но я предпочитаю >> не есть гуано. > Угу, и в результате - учишься фотосинтезировать, но, кажется, не очень мощно > пока получается. а если не делать вообще ничего — то ничего и будет. мне не нравится то, что есть. какие у меня варианты? 1) бухтеть. 2) бухтеть, и пытаться изменить то, что я изменить в силах. второй я вижу более конструктивным. всё не получится — но что могу, то сделаю. > Таки знаю. Если про переполнения signed в вон том случае - таки, > да, это только ubsan ловится. Но я плохо представляю себе как > это варнингом делать, с кодом от дидов тогда вообще все будет > варнингами сыпать. Варнинги по всей площади ведут только к тому что > на них забивают. вау! вот это самое я выше и говорил! последнее предложение — буквально слово в слово! > Де факто даже (signed int) i++ может ведь быть UB. Вопрос в > том чему i сейчас равно. А такой код чуть менее чем > везде. Это что на каждый цикл for от дидов - орать? ну, на `sprintf()` же орёт. при том, что `sprintf()` НЕ может привести к UB, в отличие от. > Ты что, сделал почти-хруст прямо из сишки? нет, ровно наоборот, хихи. в целях природы обузданья, да — берём картину мирозданья… в общем, скорость, проклятая скорость. не та, что наркотик. итерационные оптимизации алгоритма сортировки привели к тому, что гоцэцэ сошёл с ума. в данном случае это была игра (нет, я не в геймдеве, так, люблю иногда на досуге игори пописать для себя), где на каждом кадре надо много чего сортировать. >> и никто за много лет не заметил. ни в доказательствах, ни в >> рабочей программе. я-то понимаю, как работают мои алгоритмы. > Это представляет ценность только для тебя. А для остальных этот код - > одно большое минное поле. Особенно при попытке что-то там поменять. а не надо что-то менять там, где ничего не понимаешь. все целее будут. я вот не лезу править libopus, например. > И говоря за стандарты - такое вероятно не > пройдет какой-нибудь MISRA чекер, и - поделом. конечно, не пройдёт. я даже не собирался его проходить. мастер может нарушать правила когда ему надо именно потому, что при необходимости он умеет их соблюдать. >>> И конечно ни для каких критичных применений такой код ни-ни. >> ничего, применяю. пока что никто не взорвался и не помер. > Я б вообще в критичном коде указатели лишний раз трогать не стал. > Кроме может каких указателей на кастомные struct, где тип форсится достаточно > жестко и облажаться довольно сложно. а у меня нет фобии указателей: инструмент как инструмент. опасный — ну так не надо ним направо и налево размахивать. доказал правильность исходного алгоритма, доказал тождественность трансформаций — и всё. >> да знаю я, знаю, что «нормальные люди» считают достоинством не уметь в >> программирование. зачем они при этом занимаются тем, во что принципиально не >> хотят уметь — для меня до сих пор загадка. > Во первых, программирование обычно лишь цель в достижении энных задач. однако ж в хирургию без знаний отчего-то не лезут. > Во вторых, если все шагают не в ногу с твоим величеством, это > наводит на определенные мысли. помнится, когда Дейкстра вводил понятие структурого программирования — все шагали с ним не в ногу. а я — так и вообще ничего нового не ввожу, просто следую рекомендациям корифеев. >> всегда приятно читать, как люди гордятся тем, что *иногда* выпускают софт с >> проверками надёжности. такая редкая штука, что стоит особого упоминания. > Тебе не приходило в голову что это сильно зависит от характера софта? конечно. только немного иначе: иногда можно позволить себе выпускать софт без проверок, а не иногда можно позволить себе выпускать софт с проверками. > Скажем если его внешний мир в виде сети долбит недоверяемыми данными > - одно, а если это процессинг моих локальных доверяемых данных, нет > никакого смысла гробить время проца на проверки которые "always false". the famous last words. знал бы ты, сколько я всякого поймал ассертами, которые совершенно точно никогда-никогда не провалятся. кстати, ассерты — это ещё и полезные хинты для компилятора, которые позволяют явно задавать assumptions, а не гадать, что же там компилятор понавыводил и на основе этого понаоптимайзил. > Квинтэссенция современной инженерии: оптимизация bang per buck. Ну или в данном случае > - потратить минимум своих сил, создав максимум проблм атакующему. сэкономить своё время за счёт потраченого времени пользователя. программисты убили больше людей, чем любые маньяки — достаточно просто пересчитать потраченое пользователями время на ненужные ожидания, лишние действия, падения софта… когда я приду к власти, мы будем вешать программистов на столбах по обвинениям в массовых убийствах. ;-) >> да не при чём. просто усердно меня убеждаешь, что простейшие проверки — >> это очень, очень сложно. прелестный мир сишечки. > Это не "сложно" но > 1) Дрфига унаследованного кода от раздолбаев. который в первую очередь нуждается в проверках — но там их как раз и нет. > 2) Ряд проверок не халявны по скорости в рантайме. а это, например, потому что сишечка — очень плохой язык. ту же информацию про массивы сишечка дропает при первой же возможности — в итоге без нарушения ABI нормальную проверку индексов, например, не сделать. в языке, который информацию не дропает — эта проверка стоит ничего, потому что один cmp с известным значением (которое в цикле оптимизатор всё равно положит в регистр), один jump not taken. не надо меня убеждать, что на современных камнях это очень большая цена — даже на Z80 это не так уж дорого (хотя и ощутимо, конечно). >> только некоторые их признают, а некоторые — нет. авторы гоцэцэ предпочитают не >> признавать. > Вот не скажи, я знаю и примеры признания ими багов. да, эти досадные события иногда ещё случаются. надеюсь, в будущем пофиксят. >> -Wall. что-то не ругается. видимо, это не настолько важная штука, как ты >> мне пытаешься доказать. по крайней мере с точки зрения авторов гоцэцэ. >> зато легальный и безопасный вызов `snprintf()` — очень, очень опасная. > Так у вон того return a+b для signed тоже так то были > легитимные, безопасные применения. С фига такие двойные стандарты? При том кажется > у нас обоих. я не вижу двойных стандартов. вызов `snprintf()` НЕ приводит к UB никак и никогда. вызов `+` на знаковых целых — запросто. но про UB не кричат, зато про валидное применение, которое UB дать не может — ещё как. >> тоже мне проблема. ну, сделаю новый бэкэнд к компилятору — дело нехитрое. >> во что надо — в то финальный SSA и спою. > В мои цели так по жизни вообще совсем не входит написание бэкэндов > компиляторов. бывает. зря, конечно. иметь свой компилятор очень удобно. >> мой компилятор оберона говорит, что статистически мало отличимо от zero cost. такая >> вот столь любимая тобой практика. > Угу, от сишки то с lto? Что-то мне кажется, что кой-кто мне > в лучшем случае говорит не всю правду, на манер майкрософт. адская числодробилка с кучей tight loops, в которых проверки, отрабатывает за примерно 20.5 секунд. та же числодробилка без проверок — за примерно 20.2 секунды. это настолько близко к zero cost, что можно вообще не париться. то же самое на сишечке — примерно в полтора раза быстрее. meh. обе руками векторизованые — разница в пределах статистической погрешности. если уж хочешь более-менее статсы — то мой оберон в 1.2-1.7 раз медленней, чем gcc -O2. при этом компилирует ~600 кб исходного кода за 170 миллисекунд (считаем с прогретыми i/o кэшами, конечно). меня устраивает. я могу и больше оптимизаций сделать — но они кардинально ничего не изменят, зато скорость компиляции упадёт ощутимо. > 1) Null deref полностью проверить при компиле в произвольном виде невозможно. ну так я в рантайме проверяю. оно недорого. > 1a) У меня был и ЛЕГИТИМНЫЙ повод выставить указатель 0 да без проблем, кто ж запрещает-то? `SYSTEM.GET()` тебе в помощь. или отключи проверки — это *мой* компилятор, что как хочу — то так и делаю. управление проверками возможно для всего модуля, для конкретной процедуры, для одного конкретного выражения. выбирай что надо. да, opt out. чтобы гуанокод выглядел как полагается — уродливо. > Потому что могу и с этим, и без. а я в своём компиляторе не могу, конечно. > А ты, говоря про zero cost, так же сможешь вообще? см. выше. > Так что как видишь, в моем случае я могу выбирать - хочу > ли я вон то с такой ценой, или нафиг. скажи, а ты можешь выбрать такой вариант: вытесняющая многозадачность с автоматически генерируемым компилятором кодом проверки переключения задач? ну, грубо говоря: каждые n инструкций компилятор вставляет код декремента переменной кванта, и если она ноль — вызов шедулера. такая вот хитрая многозадачность, которая выглядит как настоящая, но намного более управляема. мне вот понадобилось — и за вечер компилятор этому научился. при этом исходный код проекта мне менять не пришлось. ты так можешь? > Безопасные песочницы - для детишек. А мне можно и не совсем > безопасные вещи, если я понимаю соотношения. мягко намекаю в очередной раз, что на обероне написаны полноценные оси на bare metal. как ты думаешь: предоставляет он средства обойти системы безопасности, если очень надо? >> хвалёный gcc не умеет в symbolic analysis, и не может доказать, что >> в цикле проверка не нужна, потому что out-of-bounds никогда не будет? ну ой. > Вообще, с LTO он это довольно неплохо умеет. вообще-то в LTO — если я верно помню — уже недостаточно информации для полноценного символического анализа. не путай его с VRP. > Но даже так - > это все срабатывает далеко не на 100% кода, ибо довольно часто > все зависит от заранее неизвестных входных данных. то есть, твой код индексирует массив неизвестными индексами, ничего не проверяя при этом? ой. а если проверяя — то символический анализ это увидит. и даже сможет убрать лишние внутренние проверки, переписав их во внешние (не всегда, но часто). > Как ты там собрался "доказывать" что я получу с ADC, радиолинка и > проч? Там что угодно может быть. И в этом случае - > нравится, не нравится, рантайм проверка будет. ну и прекрасно. пусть будет. а вот assert-хинты компилятор уже потерял (или проигнорировал), например. > но вот компилеру это все - так сразу не видно. зато ему можно подсказать assert-ами. > И я все же вижу определенные двойные > стандарты когда некто парится bounds check, но silent truncate его не > парит почему-то а я тебе расскажу rationale: мне не нужны *все* проверки. мне нужны проверки, которые гарантируют, что я случайно не испорчу левую память, и что не получу в арифметике out-of-range значение. всё. это не защита от уязвимостей, это защита от простых ошибок с большими последствиями. я бы и арифметику не трогал, если бы в целочисленной системе современных камней можно было иметь целочисленный NaN, который удобно ловить в стратегических местах. но такого нет, так что пришлось сделать overflow checking. для float-ов переполнения не проверяются, там мне это процессор сделает, гарантируя заражение результатов NaN-ами или inf-ами. >> в отличие от `snprintf()` — плюс с целыми знаковыми может привести к UB. > Урезание строки неожиданным для программера образом тоже может сломать логику программы. есть большая разница между «сломать логику» и UB. ты же в курсе, что второе по стандарту даёт компилятору сишечки карт-бланш на любые глупости? > в пакости типа avr. (Удачи тебе в програминге бэка этому странному > уродцу, кст.) у меня пока такой задачи нет. будет — сделаю. не боги горшки обжигают. а если не смогу… ну, значит, не смогу. научу свой оберон транслировать в сишечку, подумаешь. с учётом конкретной специфики конкретного компилятора под конкретное железо. >> потому что ключи ищут не там, где потеряли, а там, где светло? > Такое тоже бывает. Но положа руку на сердце, идея писать бэк кодогенерации > для допустим AVR ничего кроме благоговейного ужаса у меня не вызывает. идея сделать что-то типа libopus у меня тоже. вот и не делаю. ;-) > Древние уже сделали почти чудо как-то натянув сову относительно нормального си > на ЭТО. В мои планы занятие такиими извратами не входит, хорошо > что я могу отдать результату мучений древних свой код и получить > бинарник. а у меня есть два варианта вместо одного: транслировать в сишечку, или сделать кодоген самому. всяко выбор побольше. ;-) >> отлично. я написал `(void)snprintf(…)`. почему оно не заткнулось? почему такое вообще >> попало в официальный релиз? гоцэцэ совсем перестали тестировать? ну, я бы не удивился. > А я знаю? Вариантов может быть более 9000. Ты даже ссыль на > это не накинул. потому что сходу не нарыл, а ссылку в своё время от ярости не схоронил (вытер вообще все ссылки на багтрекер гоцэцэ из закладок, потому что никогда больше не собираюсь туда возвращаться). виноват, да. за это прошу прощения. > Это в принципе обычно для статических анализеров и компилеров, они могут и > перестраховываться по состоянию на сейчас. отлично. дайте мне метод в коде сказать: «заткнись, собака, и делай что царь приказал!» > А у тебя были какие-то идеи лучше как этот класс багов ловить > и при этом не жестить? Хотя с void в принципе не > так уж плохо придумано. да, тот самый `(void)`. просто, удобно, явно показывает, что я хочу opt-out, и именно в этом конкретном месте. это ж не первый хак такого рода в гоцэцэ — начиная от `(void)arg;`, и до `a = a;` (гоцэцэ это специально опознаёт). > Если на ВСЮ целочисленую математику проверок в принудиловку навешать - это уже > не будет си. так-то в сишеке вообще никаких ворнингов не было. и даже в стандарте, если я верно помню, речи про ворнинги нет. >>> Реальности изменились, tradeoffs - тоже. И теперь стандарты кодинга стали жестче. >> а программирования — остались какими были. > А вот это уже решать не тебе, и не мне, увы и > ах. почему это не мне? в моих проектах — мне. > В каком-то роде да. Я так понимаю что где можно подрезать крылья > - чтобы раздолбавить стало неудобно, подрезают. я всё ещё не понимаю, зачем понадобился ворнинг о легитмном применении библиотечной функции, с чётко прописаными в документации гарантиями. там даже ситуация «в конце строки не будет нуля» невозможна. >>> Расчистка барахла по площадям. >> ой, а кто же там намусорил-то? > Диды с их чудным кодингом. диды писали на сишечке. там `+` не делал UB, это было очень даже defined. > И это вообще-то вопрос не к GCC - а к стандартизаторам. да. но почему-то девелоперы гоцэцэ предпочитают ломать ABI, а вот стандарты — священны. по каким причинам один стандарт священне другого? а я скажу: что позволяет лучше выглядеть в benchmark game — то святое. остальное можно ломать как угодно. и плевать на код из реального мира: не для этого гоцэцэ делается. > Заодно посмотрим что стайка высокомерных снобов от академа может своим ходом и > чего стоят их блабла, и куда этот вектор приведет. к Oberon System и AOS, например. ничего даже отдалённо такого же удобного и мощного, при этом такого же простого, до сих пор в «индустрии» не сделали. >> потому что большинство людей или молча жрут то, что им скармливают авторы >> гоцэцэ (ты тут уже который пост мне доказываешь, что надо жрать >> и благодарить за тёплую шапку), > Хуже для тебя и дидов - я поддерживаю этот курс, из-за моих > интересов к управляющим системам. не, для меня таки в итоге оказалось лучше. если бы гоцэцэ не так активно ломали — я бы продолжал ним пользоваться вместо запиливания своего компилятора. потому что я таки ленивый. но ситуация дошла до: «довольно это терпеть!» > Но между нами даже хрустики проверяют математику на врап только в debug > билдах. Т.е. как сишка с ubsan примерно. В release - слишком > дорогое удовольствие, увы и ах. я не покупаю результаты benchmark game. ты же понимаешь, что можно сконструировать бенчмарк, который покажет любой нужный результат? > в третьих - попробуй сделать современный GCC или > шланг с LTO по скорости и размеру кода. ну, я выше немного про это написал. у меня нет задачи «быстрее гоцэцэ», у меня есть задача «достаточно быстро для меня». будет нужно ещё быстрее — тогда и займусь. пока что не нужно. это как раз защита от оверинжиниринга: остановиться, когда достаточно, а не бесконечно бежать за идеалом. > А простой кодоген, увы, не сможет в многие оптимзации и код будет хуже. а оптимизации вообще очень процессоро-зависимы. соответственно, при необходимости я скорее буду делать паттерн-матчинг в бэкэнде (который будет сворачивать инструкции в суперинструкции), подточеный под конкретный камень. это в среднем даёт больший выигрыш, чем 100500 оптимизаций по SSA (хотя оптимизации по SSA я тоже делаю). > Да, я совсем не хочу пасквиль > галимый с неотключаемыми рантайм проверками математики как системный ЯП. удивительно — Вирт никогда и не позиционировал паскаль как что-то большее, чем язык для обучения. поэтому он сделал модулу-2 и оберон.
	Ответить | Правка | Наверх | Cообщить модератору

	290. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (264), 25-Ноя-24, 17:09
	Допустим, Кернигана и Ритчи оставили в покое. А в какое плодотворное русло направлять усилия, совершенно новые языки пилить? Так эти усилия и так полны плодами.
	Ответить | Правка | К родителю #274 | Наверх | Cообщить модератору

	299. Скрыто модератором	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 18:43
	Блин я тоже не знаю, что делать!
	Ответить | Правка | Наверх | Cообщить модератору

	305. Скрыто модератором	+/–
	Сообщение от Аноним (153), 25-Ноя-24, 21:09
	Что делать, что делать... Займись собой, обрасти семьёй, подумай о роде, народе и природе. Если так важно гоняться за производительностью и малым использованием памяти, то ассемблеру альтернативы нет.
	Ответить | Правка | Наверх | Cообщить модератору

	352. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от _ (??), 28-Ноя-24, 06:15
	> Допустим, Кернигана и Ритчи оставили в покое. Похоже таки отпустили на пенсию :) > А в какое плодотворное русло направлять усилия, совершенно новые языки пилить? Так эти усилия и так полны плодами. Это да :) Но это - другое. А для Си - для меня самая большая хотелка - сделайте в нём модули (да хоть как в Go) и уберите нах инклюды ... а может даже и весь препроц! 8-о ... хотя наверное это уже ыкстрмизьмЪ :)
	Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

	353. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от arisu (ok), 28-Ноя-24, 09:33
	> А для Си - для меня самая большая хотелка - сделайте в > нём модули это слишком смелая концепция. помилуй, идее модулей всего-то каких-то пол-века. кто ж такой непровереный на практике новодел в серьёзный язык позволит добавить?!
	Ответить | Правка | Наверх | Cообщить модератору

339. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Я (??), 26-Ноя-24, 22:27
strdup очень безопасная функция, особенно когда принимает неалоцированную строку, питонисты добились её утверждения в стандартные
Ответить | Правка | Наверх | Cообщить модератору

347. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Соль земли (?), 27-Ноя-24, 09:52
35 лет допиливали язык. Вот это я понимаю поддержка!
Ответить | Правка | Наверх | Cообщить модератору

348. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от InuYasha (??), 27-Ноя-24, 20:49
Вот, реально задалбывает в плюсах: ну ввели вы новую погребень - ДАЙТЕ ЛЮДЯМ ЭТО ПРОВЕРИТЬ! > добавление константы nullptr #if !defined(nullptr) - хрен вам! сосите лапу. #define nullptr (void *)0x0 // условно так уже достало писать слой портабельности на все компиляторы с 90ых годов!..
Ответить | Правка | Наверх | Cообщить модератору

349. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
Сообщение от InuYasha (??), 27-Ноя-24, 20:55
> В стандарт включены операторы typeof и typeof_unqual, 20 лет просил об этой хреноте и всё равно сделали что-то ж...не то что хотелось. А всего-то надо было typeof(a) == typeof(b)...
Ответить | Правка | Наверх | Cообщить модератору

	359. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 28-Ноя-24, 19:14
	>> В стандарт включены операторы typeof и typeof_unqual, > 20 лет просил об этой хреноте и всё равно сделали что-то ж...не то что хотелось. А всего-то надо было typeof(a) == typeof(b)... Зато комми-тет может пообсуждать это годика 3 и выпустить новый стандарт!
	Ответить | Правка | Наверх | Cообщить модератору

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

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