Аарон Баллман (Aaron Ballman), главный сопровождающий компилятор Clang и участник команд разработки стандартов WG21 (C++) и WG14 (C), начал обсуждение добавления в компилятор Clang режима усиления безопасности. Новый режим позволит разом активировать набор опций для усиления защиты по аналогии с добавленным в GCC 14 флагом "-fhardened", при котором включаются опции "-D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -ftrivial-auto-var-init=zero -fPIE -pie -Wl,-z,relro,-z,now -fstack-protector-strong -fstack-clash-protection -fcf-protection=full"...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63675
А всё почему? А всё по той причине, что сишечный фронтенд не может что-то адекватное генерировать. Приходится костыли в бекенд ставить.
> А всё по той причине, что сишечный фронтенд не может что-то адекватное генерировать. Приходится костыли в бекенд ставить.Так а какие еще варианты, если язык дефективный by design. Это все-таки дешевле, чем переписывать миллионы легаси кода с C и C++ на Rust.
Дак и не надо всё переписывать. Надо только самое важное.
Ну вот один в истории так же подумал, а потом слонов через горы повёл.
и он не переписал самое важное, собственно поэтому проект провалился
Его ошибка в том, что он не реализовал победу при Каннах, а не в потерях при переправе.
> Дак и не надо всё переписывать. Надо только самое важное.У хруста дефолтным кодогенератором, извините, что? И на каком яп? А, на плюсах? Оок! :)
Зависит от контекста. Если у нас что-то критичное к безопасности, это означает, что переписать миллион строк на другой язык будет дешевле, чем разгребать последствия эксплуатации дыреней.Вообще переписывание чего бы то ни было (в том числе на тот же язык) является рефакторингом. Иногда это дешевле поддержки легаси. Иногда нет. Зависит от.
> Если у нас что-то критичное к безопасности, это означает, что переписать миллион строк на другой язык будет дешевле, чем разгребать последствияЧто-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано. В этих областях уж точно не сидели бы и не ждали до 202* года, пока им разработчики ГЦЦ/Шланг с барского плеча отсыпят костылей для затыкания дыр в недоязыках из 70-80.
Эти флажки как раз для 95% разработки, где на безопасность наплевать, причем настолько, что они в большинстве случаев даже эти опции компилятора не станут включать под предлогом того, что будут просадки производительности.
Для критичной безопасности выбор языка не имеет значения. К слову, для Си есть стандарты безопасного программирования.
В прочем, они тоже не имеют значения. Решает формальная верификация кода, а не эти игрища с "мой язык круче".
Подтверждаю. Работаю в гражданской авиации где есть авиационные стандарты на верификацию и тестирования кода. Используются компиляторы обычно старенькие и все почти полностью на чистом Си со стандартом ANSI, С89, С99 в зависимости от категории надежности ПО. На плюсах доказать что код работает так как положено очень тяжело. Так вот доказательство что все работает как надо по разработанным требованиям к ПО (а это обязательна часть при разработке) достигается модульным тестированием(по требованиям низкого уровня), тестированием по требованиям высокого уровня, тестированием по требованиям комплексным и системным. Ну и пилоты испытатели в конце концов все тестируют на страх и риск. Ну и соответственно самые высокоуровневые тесты не всегда автоматизированы иногда они как протокол ручных манипуляций по приборной панели выполняются. А на уровне модульном и по аысокоуровневым требованиям конечно почти полная автоматизация со сбором покрытия и объяснением почему какое то покрытие не 100%. Пповеряетс как говорится любая операция в коде и последовательность выполнения тоже :). Это дорого и медленно, но вот в авиации лучше пока не придумали.Самолеты от этого не падают каждый раз кстати. Ну и конечно у нас embedded software а не ваши Intel Xeon с терабайтом ОЗУ. У нас ПЗУ то в десятках мегабайт измеряется на приборах часто а уж ОЗУ и подавно в десятках или сотнях КБ.
> Работаю в гражданской авиации где есть авиационные стандарты на верификацию и тестирования кода
> Используются компиляторы обычно старенькие и все почти полностью на чистом Си со стандартом ANSI, С89, С99Я сильно сомневаюсь, что бы работаете в гражданской авиации, ибо там десятилетиями используется Ада.
https://ak-12.livejournal.com/60382.html
> Так вот доказательство что все работает как надо по разработанным требованиям к ПО (а это обязательна часть при разработке) достигается модульным тестированием
Нет, дружок, доказательство, что все работает достигается в первую очередь формальной верификацией, а потом уже идут аудиты безопасности. Потому что модульные тесты, написанные ручками и уж тем более само ручное тестирование не является доказательством чего-то.
> Ну и пилоты испытатели в конце концов все тестируют на страх и риск.
Вот тут я уже заржал в голос. В авиации он работает, господи.
> Это дорого и медленно, но вот в авиации лучше пока не придумали
Уважаемый эксперт погуглит, когда Аду изобрели и когда внедрили, в частности, в область гражданской авиации?
Я в принципе могу поверить, что у вас там какая-то особенная авиация, но вот в целом по миру заредкими исключениями никто критический по безопасности софт на Си не писал и не пишет. Ибо это как минимум отсутствие злравого смысла, а в целом - верх халатности.
Ну, т.е. проверенно безопасный язык существует езё
Ну, т.е. проверенно безопасный язык существует уже десятилетия и работает. Т.е. раст нинужен от совсем нинужен
Твой Боинг из примера уже на сишечку перешёл. Твои данные неактуальные.
Человек выше говорит от своего опыта. А вы зачем-то теоретизируете, приводите ссылки в качестве доказательства. Зачем? Вы же сами не работаете в этой области получается, раз не от себя говорите. Советую поискать в интернете на чём нынче действительно программируют железо самолётное. И не статейки на ЖЖ.
> но вот в целом по миру заредкими исключениями никто критический по безопасности софт на Си не писал и не пишет.Ога-ога, а к примеру MISRA - это деза от проклятых капиталистоФФЪ! ;-)))
И раз сказал А, говори и Б - по ссылке "пересказ пересказа перезчика", деффки(С) тут вещали что в РФ Ада только у Бериева осталась...
Да и не панацея Ада, от слова НАПРОЧЬ!(С) - Ariane V не даст соврать! :-р
>Я в принципе могу поверить, что у вас там какая-то особенная авиация, но вот в целом по миру заредкими исключениями никто критический по безопасности софт на Си не писал и не пишет. Ибо это как минимум отсутствие злравого смысла, а в целом - верх халатности.
Трепло :) По ссылке которую _ТЫ_ сам привел - первый же абзац о том что для нового Лайтинга F-35 Аду выкинули сразу и полностью и пишут на ... С++ :)
Кстати про военные самолёты... . не знаю как в американской военной авиации но в российской работают по стандартам ЕСКД и ЕСПД (теперь придётся рот вымыть с мылом :) ).
И там в целом такого процесса как формальная верификация просто нет. Как с заказчиком договорился так и будет он приёмку осуществлять. Ни о какой верификации и покрытии кода тестами речь не идёт. Скорее это будет проверка работы в разных режимах и с тестами на температуры, вибрацию, удары и тд и тп. Там ответственность ещё за аварию лежит на разработчике и заводе изготовителе прибора, модуля, подсистемы и т.д. В том числе и уголовная. Поэтому более менее надёжно, но очень не одинаково от заказа к заказу и от предприятия к предприятию и прибора к прибору потому что обговоариваются условия с военной приёмкой индивидуально. Но это в РФ. Как в Америке, повторяюсь, не знаю.
"... ибо там десятилетиями используется Ада." Ну пока что за 4 года работы ни одной строчки Ада я не видел и не слышал из колег что бы кто-то с этим работал. А вот Си и моделей MATLAB из которых генерируется после тестирования Си код и компилируется в исполняемый дофига где есть и в отечественных и в европейских проектах."Нет, дружок, доказательство, что все работает достигается в первую очередь формальной верификацией, а потом уже идут аудиты безопасности. Потому что модульные тесты, написанные ручками и уж тем более само ручное тестирование не является доказательством чего-то." В целом вы правы. я сглупил. Тесты это инструмент верификации ПО. так и написано в КТ-178C. Я упор сделал на тесты потому что тут все письками мерились о языках. А тесты народу понятнее чем какие то там требования, верификации... у всех максимум есть ТЗ и тесты сделанные отдельным отделом тестировщиков. А вот ручое тестирование так же как и автоматическое тестирование применяется потому что не всегда возможно или разумно использовать автоматизированное. Только он должен выполняться по установленному протоколу разработанному в рамках процесса верикиции ПО. Раздел 6 в КТ.Потому что ты автоматизированно не можешь условные физические тумблеры переключить, хотя это только малая часть примеров.
"Я в принципе могу поверить, что у вас там какая-то особенная авиация, но вот в целом по миру заредкими исключениями никто критический по безопасности софт на Си не писал и не пишет. Ибо это как минимум отсутствие злравого смысла, а в целом - верх халатности."
Ну значит не летайте на популярных самолётах потому что там софт очень много где написан в основном на Си. Да-да и по уровню ПО "А", "B" тоже. Тут я вам документов в пример привести не могу потому что можно и на Ада писать и на Паскале с Бейсиком, главное не это и стандарты это не определяют. А вот практика определяет. Ну может кто то и на Rust написать только надо потом доказать всё равно соблюдением всех процессов жизненного цикла ПО что действительно это всё будет работать в соответствии с категирией ПО.А в целом вы позволяете себе очень вольные высказывания в мой адрес, кажется мы с вами вместе водку не пили что бы вот так вот общаться. То что есть испытательные полёты когда софт ещё проходит стадию тестирования это факт. В малой авиации это могут быть беспилотные модели, а в большой садятся пилоты и своими жизнями рискуют в какой то степени. Понятно что большинство систем отработны на земле. Сейчас летают всякие супержеты и МС-21-300 которые ещё не допущены к эксплуатации потому что не пройдены все соответствующие проверки и испытания и не выдан сертификат лётной годности.
Ну а вы можете ржать в голос дальше. Видимо для вас это вполне прилично.
Всё равно удивляет, что C (с MISRA или чем-то подобным видимо), а не Ada или вообще что-нибудь функциональное.
> Что-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано.За примерами далеко не надо ходить:
sudo
Переписали конечно, потихоньку переходят. Но процесс не моментальный.
На счёт флагов компиляции. В 95% кроме оригинального разраба какойто проги/либы никто не знает, что имеет смысл тыкать. Ещё 5% приходится на прошареных пользователей и 0% на мейнтейнеров твоего диструбутива. Тем более, что если ты включил какую-то опцию, это не значит, что код стал быстрее. Это всё надо тестить.
Контрпример: doas.
command not found: doas
> Контрпример: doas.Простите, бсд это маргинальщина даже для сего форума.
Если бы не было хурда, то я бы сказал "эталонное нинужна".
> Простите, бсд это маргинальщинаПрощаю. Поставьте Alpine Linux, там doas из коробки. Дистрибутив популярный в узких кругах. В IoT и контейнерах.
> Что-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано.Да каеш. Критичное к безопасности, если что, это всё от дырявого насквозь openssl до дырявого насквозь ядра linux с rce во всяких уринах. Даже клоуны от безопасности openbsd принипиально пишут только на C.
Использования второго языка усложнит сопровождение не в два раз, а кратно!Если бы предлагалось переписать на безопасный, надёжный и верифицируемый язык типа SPARK (ADA), то аргументы можно было ещё принять. А переписывать на ржавый - только испортить простой код.
ещё можно dafny использовать и C код генерить.вообще есть масса возможностей, поэтому раст и не нужен
> ещё можно dafny использовать и C код генерить.
> вообще есть масса возможностей, поэтому раст и не нуженесли вы такие умные, то чего ̶т̶а̶к̶и̶е̶ ̶б̶е̶д̶н̶ы̶е̶ CVE/RCE до сих пор вы дыряшечном коде? (с)
Мне как-то в комментах на этом самом форуме СИшник рассказывал, что тесты не нужны, тк он и так знает что пишет, а ждать 10 минуть чтобы PR замерджить это слишком долго)
Зачем ты пишешь дыряшечный код, а ответственность перекладываешь на других?
Если ты переписываешь с одного языка на другой, то у тебя остаётся один язык. Очевидно же.> язык типа SPARK (ADA)
На сколько сложно собрать команду из десятка программистов на Аде?
Очевидно что процесс переписывания занимает не один день. И месяцы-годы будет два языка как минимум.
Попробуйте найти хорошего специалиста который хорошо знает и C/C++, и Rust. И это пол беды. Если команда состояла преимущественно из сишников, процесс их перехода на раст будет тоже небыстрым. А бизнес простоев не любит. Поэтому будет несколько затянутых процессов одновременно:
- переписывание кода на раст;
- написание нового кода на раст;
- написание нового кода на си (да-да, мы в реальном мире, в котором идеальное не воплощается мгновенно, рук на раст сразу не хватит).
Ну, если это серьёзный проект, а не стартап на 1,5 строчки кода.
Эти процессы как раз в firefox можно наблюдать. За эти годы процент кода на rust – 12,3%.
Там не ставилась задача переписать на раст весь ФФ.
После таких слов стало понятно что вы сударь теоретик. И принимать во внимание комментарии следует соответственно.
упоминать в одном предложении си и бекенд/фронтент - кричать о своём диагнозе "веб-синьор"
Фронтенд занимается парсингом/анализом языка.
Бекенд занимается оптимизациями и генерацией машинного кода.Эти термины не относятся исключительно к вебу.
живи себе дальше в своём маня-мирке, счастье в неведении
> живи себе дальше в своём маня-мирке, счастье в неведенииОткрываешь https://clang.llvm.org/ Читаешь большие буквы в заголовке:
Clang: a C language family frontend for LLVM
...и больше не позоришься своей экспертизой.
приводить в пример вендорлокнутую хипсто-поделку - много ума не надо. наоборот, надо мало ума
Чел, ты может не заметил, но это новость о Clang и ветка обсуждения тоже о Clang.Казалось бы, опозорился - имей хотя бы самоуважение не всплывать тут больше. Но ты у нас мазохист, я смотрю... Ляпнешь еще что-нибудь? 😂
Если бы речь шла о чём-то вроде Intel Compiler, то может быть.Однако LLVM распространяется под Apache 2.0. Для сравнения GCC распространяется под GPLv3+. Копилефт лицензии, очевидно, накладывают большее количество ограничений, чем пермиссивные.
Само понятие вендорлок означает, что тебя к чему-то привязывают, обязывают что-то делать. Использование GCC означает, что тебя привязали к GNU-инфраструктуре. Кроме того использование GCC в качестве части твоих проектов обязывает тебя использовать GPL. Я, очевидно, имею ввиду использование GCC как части твоего собственного компилятора или чего-то такого.
К чему тебя привязывает использование проекта под пермиссивной лицензией? Вендорлок к чему конкретно? К качественному продукту (в сравнении с GCC)? Ну только если так.
> приводить в пример вендорлокнутую хипсто-поделку - много ума не надо. наоборот, надо мало умаИ то ли дело закачка био-метана в малые водоемы на опеннете - тяжелый умственный труд, грозящий ̶п̶о̶д̶выгоранием, да?
https://gcc.gnu.org/frontends.html
> Currently the main GCC distribution contains front ends for C, C++, Objective C, Objective C++, Fortran, Ada, Go, D, Modula-2, Rust, and Cobol.https://gcc.gnu.org/onlinedocs/gccint/Back-End.html
> A back end for a target architecture in GCC has the following parts:.
На всякий случай напомню что в небезызвесном окисленном язычке даже фронтенда как такового нету и используется фронт си++ ллвм апи
rustc является фронтендом. Фронтенд clang не используется. Дальше используется llvm, который бекенд. Ещё есть варианты с кодогенерацией через gcc или cranelift.О том, как там чего устроено есть документация: https://rustc-dev-guide.rust-lang.org/
> Дальше используется llvm, который бекенд.Но он тоже - на C++ :).
> Ещё есть варианты с кодогенерацией через gcc или cranelift.
Есть. Но по дефолту - сватается вон тот. Вон так. А gcc тем временем сможет в билд ядер с хрустом раньше чем ожидалось, кажись.
> напомню что в небезызвесном окисленном язычке даже фронтенда как такового нету и используется фронт си++ ллвм апиНет, там не используется "фронт C++". Фронтент C++ называется Clang, и прямо на его сайте в шапке огромными буквами написано "Clang: a C language family frontend for LLVM".
Фронтенд у Rust свой, как бы того не хотелось воинам против Раста.
> Реализуемые методы защиты часто приводят к отдельным несовместимостям с существующим кодом или нарушению ABI, что не позволяет активировать их по умолчанию.Таких программ единицы. В Gentoo возможно для них прописать отдельные опции сборки в /etc/portage
Ставим безопасные опции сборки и пересобираем мир.
А rust не нужен.
> В Gentoo
> пересобираем мирГентушникам нет покоя. 😂 Собирай-перекомпиляй!
Когда правильно собрал перекомпилировать не надо.
А есть люди, которые ставят приложение в пару кликов. Представляете?
> А есть люди, которые ставят приложение в пару кликов. Представляете?Вы что хотите КАК В ВИНДЕ!?
Линукс создан для страданий и превозмоганий.
Если дать людям удобный способ хотя бы устанавливать ПО нормально, то они расслабятся, размякнут и что потом?
Попросят делать UI/UX хорошо, а не как "бомж вася, по совместительству дизигнер в СПО проекте наблевал на экран" ?
> Линукс создан для страданий и превозмоганий.Второй десяток лет пользуюсь, и вижу только как страдают виндузятники, то там не работает, то чтото не ставится...а мне надо файлек расшарить, 2 строки в нжинкс, надо снапшот системы сделать - 1 команда, еще одна и скопировал на другой диск...упал впн, 1 команда поднялся другой...блин вот 0 проблем, завернуть сайт почты россии так чтобы он ходил в обход впн, как нефиг, чядн?
Ты все делаешь так)
Просто ты не учитываешь годы, потраченные на изучение этих команд и прдолинг с консолькой.
Для нормального юзера файл шарится чегез гугл-драйв в тот же 1 клик.Но рассказы про УМВР - это классика красноглазых форумов.
Если у вас все работает, то чего появляются темы "Как избавиться от щелчков при запуске приложений на системах с чипами Intel" ?
А проблемы с дровами? А с софтом?
Да- да, 2 строки в нжыдск. А то, что надо изначально нормально так пропердолиться в том, что такое нжыдск, что там где править надо. А ещё немного iptables потыкать. А так да, чё там, 2 строки, ёпт.
Текстовый вархаммер?
> А есть люди, которые ставят приложение в пару кликов. Представляете?Одно приложение? Даже и в пару кликов!!!
Эти, даже представить себе не могут, что гентушник, всего ОДНИМ нажатием на клавишу Enter может пересобрать весь мир.
А Я ОДНИМ нажатием на Enter, могу создать всю систему с нуля, пересобрать мир правильно и создать с него LiveDVD.
И с этого LivDVD могу ОДНИМ нажатием на Enter установить готовую собранную систему.
Никому, кроме тебя, не нужную?
Это ржавый не нужен, а моя система нужна всем: https://www.opennet.dev/openforum/vsluhforumID3/137467.html#294
> Это ржавый не нужен, а моя система нужна всемТвоя система нужна полторым землекопам.
А раст используют большая часть топовых фирм - именно те, кто развивают IT.Ну а рассуждение про "заговор против СПО"... оставь такой шизоидный бред дря РЕНТВ.
Они и туалетную бумагу используют, если чо.И эффективность, скорее всего, рядом
> Эти, даже представить себе не могут, что гентушник,
> всего ОДНИМ нажатием на клавишу Enter может пересобрать весь мир.Да, нужно только исправить все сломанное в portage.
А потом можно пойти попить чай на полдня или даже на день, смотря на каком унитазе он решил попомпилять.
Ну с Rust ситуация еще хуже, так как нет стабильного ABI. Там для новой версии компилятора нужно перекомпилировать каждый раз вообще всё или, отказываясь от безопасности при работе с памятью, использовать C ABI.
> Ну с Rust ситуация еще хуже, так как нет стабильного ABI.Разве у C есть какое-то ABI ?
Что-то в стандарте я такого не видел.> Там для новой версии компилятора нужно перекомпилировать каждый раз вообще всё или, отказываясь от безопасности при работе с памятью, использовать C ABI.
C++ как-то с этим живет - у них примерно каждые 3 версии ломают.
И ничего, никто не умер, язык повсеместно используется и для прикладного ПО и для ОС.
> Разве у C есть какое-то ABI ?Посмотрите внимательно на диск своего компьютера. Все dll/so в нем используют один и тот же стандартный для этой операционной системы С ABI.
Так же поступает и Rust при спецификации extern "C".
Если бы это было иначе, то ни о каком динамическом связывании вообще речи быть не могло. Прикладная программа даже к операционной системе не смогла бы обратиться.> C++ как-то с этим живет
Во-первых, C++ поддерживает C ABI. Так же как и Rust. И с теми же ограничениями и проблемами с безопасностью, что в этом смысле уравнивает C++ и Rust.
Во-вторых, Clang и GCC уже давно поддерживают Itanium C++ ABI. Альтернативные расширенные варианты предлагают некоторые фреймворки, как, например, Qt.
Ты используешь эти флаги? В частности, - D_FORTIFY_SOURCE=3 интересует. Я читал, он прям сильно роняет производительность
> Я читал, он прям сильно роняет производительностьНу, за безопасность нужно платить. Главное, что Раста нет.
Раст или так же роняет производительность либо имеет под собой худшую защиту.
> Раст или так же роняет производительность либо имеет под собой худшую защиту.Нет. В расте за лучшую защиты ты платишь размером временных файлов и временем компиляции во время которого проводятся все проверки - анализ лайфтаймов, владение, типизация и так далее.
Вот только программа компилится только один раз, а запускается на порядки больше раз (за исключением гентушников-ноулаферов, которым только дай покомпилять).
А рантайм проверки роняют производительность каждому юзеру и для каждого запуска.
Но диды продолжаю ныть "раст не влазит на мой HDD 40GB", "лиса компилируется долго", "это нужно целую билдферму делать".
> А рантайм проверки роняют производительность каждому юзеру и для каждого запуска.Это небольшая цена за победу над Растом. Я лично готов и большее терпеть и превозмогать. Надо будет - и ядро буду сам пересобирать с отключенным Растом.
> Это небольшая цена за победу над Растом.Вы готовы бороться с растом, а лучше бы боролись с дырявостью сишки.
> Я лично готов и большее терпеть и превозмогать.
Да без проблем. Терпите и превозмогайте.
> Надо будет - и ядро буду сам пересобирать с отключенным Растом.
Пока дрова на нем не будут писать))
Хотя можно страдать еще больше и сидеть без дров.
> Вы готовы бороться с растом, а лучше бы боролись с дырявостью сишки.Я в сишке опции компилятора включу и буду сидеть в безопасности. А чтобы бороться с Растом мне вообще ничего не нужно делать (ну, кроме написания опеннетных комментариев).
> Пока дрова на нем не будут писать))
> Хотя можно страдать еще больше и сидеть без дровОй, напугали. Мне чтобы с консолью сношаться эти ваши растовые дрова и не нужны.
> "раст не влазит на мой HDD 40GB"И в чём они неправы?
> И в чём они неправы?В том, что для каждого времени и для каждого инструмента есть свои требования.
HDD 40GB должны остаться где-то... во временах Maxtor, если вы еще помните такую фирму))Новый инструмент дает новые гарантии, но и просит "оплатить" это требованиями к железу.
Если ваше железо не соответствует - это ваша проблема.Вы же не возмущаетесь что современное авто невозможно нормально отремонтировать в гараже?
Вот тут аналогичная ситуация.
> А рантайм проверки роняют производительность каждому юзеру и для каждого запуска.Ещё раз. Гарантии безопасности в C, C++ даются при исполнении программы. И от ржавого требуется в принципе тоже. При компиляции некие проверки есть. При запуске проверок частных нет, есть связывание всех библиотек. При работе есть постоянные проверки памяти - проактивная защита. И эти постоянные проверки работы с памятью в правильных ядрах OS на правильных CPU не влияют на производительность!
> И эти постоянные проверки работы с памятью в правильных ядрах OS на правильных CPU не влияют на производительность!О как! Правильные ОС и ядра у нас поди на чистой магии работают?
Не на магии, а на спец инструкция процессоров и действительно ядра OS могут отлавливать переполнение буфера постранично без накладных расходов: https://www.opennet.dev/openforum/vsluhforumID3/137467.html#304
Цена этого - или многократное дублирование кода при статическом связывании, или использование C ABI для динамического связывания, вообще отказавшись от подобных проверок.
И когда хост k8s начитает из-за Rust требовать в разы больше оперативной памяти даже по сравнению с .NET или Java, это уже, обычно, не о 40ГБ речь, а сотнях гигабайт оперативки.
> Цена этого - или многократное дублирование кода при статическом связывании, или использование C ABI для динамического связывания, вообще отказавшись от подобных проверок.Но все внутренние проверки и гарантии останутся.
Т.е будет какое-то unsafe связывание, а дальше стандартные проверки.> И когда хост k8s начитает из-за Rust требовать в разы больше оперативной памяти даже по сравнению с .NET или Java, это уже, обычно, не о 40ГБ речь, а сотнях гигабайт оперативки.
Ну... не все занимаются контейнерами.
Для локальных приложений это вообще не важно.
> Т.е будет какое-то unsafe связывание, а дальше стандартные проверки.Что проверять будете, если на входе в параметрах нечто инородное для Rust?
>> И когда хост k8s начитает из-за Rust требовать в разы больше оперативной памяти даже по сравнению с .NET или Java, это уже, обычно, не о 40ГБ речь, а сотнях гигабайт оперативки.
> Ну... не все занимаются контейнерами.
> Для локальных приложений это вообще не важно.Всё идет к тому, что у большинства пользователей локальным приложением будет только веб-браузер или этот же веб-браузер в electron. И все пользователи при этом так или иначе через свой браузер будут обращаться к k8s.
>> Т.е будет какое-то unsafe связывание, а дальше стандартные проверки.
> Что проверять будете, если на входе в параметрах нечто инородное для Rust?Так же как сейчас проверю в связывании с СИ кодом.
Если что-то не то - будем падать.
> Всё идет к тому, что у большинства пользователей локальным приложением будет только веб-браузер или этот же веб-браузер в electron.Кол-во нативных приложений указывает, что вы слегка преувеличиваете.
> И все пользователи при этом так или иначе через свой браузер будут обращаться к k8s.
Значит пока раст будет только на машинах пользователей.
Сколько лет жили с СИшным кодом на серваках, думаю еще поживут.
> Так же как сейчас проверю в связывании с СИ кодом.
> Если что-то не то - будем падать.То есть, в случае необходимости динамического связывания, Rust начинает проигрывать C++, у которого есть Itanium ABI.
> Кол-во нативных приложений указывает, что вы слегка преувеличиваете.
Ах да, игры забыл. А так непонятно о чем речь. Даже AutoCAD у нас теперь на серверах рендерится, хотя и там Rust не при делах.
О каких десктопных приложениях Вы вообще речь ведете?>> И все пользователи при этом так или иначе через свой браузер будут обращаться к k8s.
> Значит пока раст будет только на машинах пользователей.Если учесть, что именно enterprise финансирует подавляющее большинство open source в своих целях, это обозначает, что Вы предалагаете Rust позиционировать исключительно для любителей и энтузиастов?
> То есть, в случае необходимости динамического связывания, Rust начинает проигрывать C++, у которого есть Itanium ABI.Проигрывать по какому параметру? С++ останется при этом С++ом. С наследственными проблемами.
Неужели у С++ появились проверки владения в compile time?> Ах да, игры забыл. А так непонятно о чем речь. Даже AutoCAD у нас теперь на серверах рендерится, хотя и там Rust не при делах.
У кого "нас"?
AutoCAD запросто работает локально, на help.autodesk даже есть инструкция как все отключить от интернета.
Ну и второе, неужели каждый рендер будет в своем контенере и будем трястить на десятком мегабайт? Сам рендер может и много гигов скушать.> О каких десктопных приложениях Вы вообще речь ведете?
Офис например. Не все используют онлайн сервисы.
> Если учесть, что именно enterprise финансирует подавляющее большинство open source в своих целях,
Если учесть что раст использует и продвигает гугл в андроиде, то боюсь серваки там на последнем места. А вот ноуты с хромиумом - возможно.
Значит те кому надо - AWS, Meta, microsoft - пусть и добавляют то что нужно для серверов.
Хотя погоди-те, последние как раз сделали Hyperlight (opennet.ru/opennews/art.shtml?num=62226) и OpenVMM (opennet.ru/opennews/art.shtml?num=62070).
Как они смогли, при отсутствии ABI?> это обозначает, что Вы предалагаете Rust позиционировать исключительно для любителей и энтузиастов?
Вообще никак не связано)
>> То есть, в случае необходимости динамического связывания, Rust начинает проигрывать C++, у которого есть Itanium ABI.
> Проигрывать по какому параметру?У so/dll на Rust, вызванном по C ABI нет вообще никакой информации о параметрах. Есть только голые структуры без трейтов, про которые только можно надеяться, что они соответствуют описанию при сборке этого so/dll.
Тогда как у C++, благодаря RTTI в Itanium ABI, есть объекты известного типа, с известными свойствами и методами. И лезть внутрь этих объектов напрямую, а не через эти свойства и методы, ему совершенно не требуется.
> С наследственными проблемами.
С этим у Rust действительно проблемы. Там где в C++ достаточно наследования, на Rust приходится рефакторить весь проект.
> Неужели у С++ появились проверки владения в compile time?
Что Вы собрались проверять при компиляции so/dll, когда понятия не имеете, кем и как она будет вызываться?
>> Ах да, игры забыл. А так непонятно о чем речь. Даже AutoCAD у нас теперь на серверах рендерится, хотя и там Rust не при делах.
> У кого "нас"?У моих текущих клиентов.
> AutoCAD запросто работает локально
Только медленно и печально, потому что каждому конструктору RTX 6000 PRO в рабочую станцию не поставишь. А на сервер одну на отдел - вполне.
> Ну и второе
Бессмысленный спич, я же указал, что тут Rust вообще не при делах. Чем он может помочь в CUDA? Когда он научился безопасной работе с памятью GPU и DMA?
>> О каких десктопных приложениях Вы вообще речь ведете?
> Офис например.И какой же офис есть на Rust?
> Не все используют онлайн сервисы.
Но всех усиленно туда выгоняют. Обычно, в корпоративный on-premises.
>> Если учесть, что именно enterprise финансирует подавляющее большинство open source в своих целях,
> серваки там на последнем места. А вот ноуты с хромиумом - возможно.Я так и писал - разве что браузер )))
> Значит те кому надо - AWS, Meta, microsoft - пусть и добавляют
> то что нужно для серверов.Так не дают. Уже множество попыток было. Rust community категорически отказывается от стандартизации языка и его ABI. Поэтому всё, что есть, это несовместимые друг с другом костыли над C ABI, как, например, в Redox.
> Хотя погоди-те, последние как раз сделали Hyperlight (opennet.ru/opennews/art.shtml?num=62226)
> Как они смогли, при отсутствии ABI?Естественно, через C ABI, что видно сразу же на гитхабе:
pub extern "C" fn hyperlight_main()Очередной костыль, совместимый исключительно сам с собой.
> С этим у Rust действительно проблемы. Там где в C++ достаточно наследования, на Rust приходится рефакторить весь проект.Какой ужас! Такие страдания.
Как другие компании справляются - даже не представляю.
Надеюсь вам не приходится писать на расте.> Что Вы собрались проверять при компиляции so/dll, когда понятия не имеете, кем и как она будет вызываться?
Ну чтобы длл-ка внутри не вышла за пределы буфера и не попортила память.
> У моих текущих клиентов.
Значит им не повезло. Печалька.
> Только медленно и печально, потому что каждому конструктору RTX 6000 PRO в рабочую станцию не поставишь. А на сервер одну на отдел - вполне.
Т.е одна на весь отдел - тянет, а тут оказывается каждому 6000 PRO надо...
Неужели PRO 4000 не вытянет?> Так не дают. Уже множество попыток было. Rust community категорически отказывается от стандартизации языка и его ABI. Поэтому всё, что есть, это несовместимые друг с другом костыли над C ABI, как, например, в Redox.
Удивительно, они финансируют, а сообщество им палки в колеса ставит.
Значит или прекратят финансирование, или найдут аргументы.
> Естественно, через C ABI, что видно сразу же на гитхабе:
> pub extern "C" fn hyperlight_main()Т.е оно все таки работает)
> Очередной костыль, совместимый исключительно сам с собой.
А им нужно быть совместимым еще с кем-то?
ps мне cлегка интересно, услышу я печальную историю про DMA или это будет в след раз)
> Какой ужас! Такие страдания.Сочувствую. Не думал, что мой рассказ про RTTI в Itanium ABI так сильно ударит по Вашему самочувствию. )))
>> Что Вы собрались проверять при компиляции so/dll, когда понятия не имеете, кем и как она будет вызываться?
> Ну чтобы длл-ка внутри не вышла за пределы буфера и не попортила
> память.Для начала, как Вы узнаете где буфер и где размеры? Будете верить, как в Слово Божье, что по какому-то смещению в этой структуре указатель на буфер, а по другому смещению - размер этого буфера? )))
Я же выше на пальцах Вам показал, что без RTTI Вы тут бессильны!>> У моих текущих клиентов.
> Значит им не повезло. Печалька.Наоборот. То что на 24ГБ рендерилось медленно и печально, на 96ГБ рендерится моментально.
> Неужели PRO 4000 не вытянет?
Тянула. Медленно и печально. Например, ЭРШРД-5250 в 24ГБ точно не лезет. Так как они выпускались на печально известном Азовмаше, то я думаю понятно, что самим приходится заниматься их обслуживанием и модернизацей.
> Удивительно, они финансируют, а сообщество им палки в колеса ставит.
Вы о чем вообще? Rust foundation за прошлый год из полученных $3.72 млн. на развитие языка потратил жалкие $413 тыс.
Для сравнения, за этот же год Linux Foundation получил около $300 млн. и потратил на развитие системы свыше $200 млн.> А им нужно быть совместимым еще с кем-то?
Если это локальный проект - нет. Если хотите, чтобы проект был востребован на рынке - обязательно.
Наиболее популярно с этим можете ознакомиться тут https://ru.wikipedia.org/wiki/%D0%A1%D1%...> ps мне cлегка интересно, услышу я печальную историю про DMA или это
> будет в след раз)В данном случае была речь про DMA между графической и основной памятью. И тут Rust точно не у дел. Что Вы сами и подтверждали )))
На развитие чего?Тут даже была пeрдakо-поджигающая статья "Доля расходов Linux Foundation на разработку ядра уменьшилась в 2024 году до 2.3%"
opennet.ru/opennews/art.shtml?num=62456Вижу "Расходы на не связанные с ядром проекты увеличились с $171.8 до $193.7 млн (64.6% от всех расходов);"
Так что 400к из ~4млн выглядит гораздо честнее чем "разработка" ядра.
> На развитие чего?Свыше 900 проектов, поддерживаемых Linux Foundation. Или Вы хотели бы, чтобы эти $193 млн. оказались на депозите или были вложены в ценные бумаги ФРС США?
А может Вы, в отличии от Торвальдса, считаете что разработка Linux Kernel недостаточно финансируется?
Что Вы увидели плохого в том, что Linux Foundation получает финансирование в десятки раз большее, чем необходимо для разработки Linux Kernel?
> Или Вы хотели бы, чтобы эти $193 млн. оказались на депозите
> или были вложены в ценные бумаги ФРС США?Это не такое плохое решение, если задуматься))
> А может Вы, в отличии от Торвальдса, считаете что разработка Linux Kernel
> недостаточно финансируется?А вы считаете что хорошо финансируется?
Может еще и цитату Торвальдса приведете, где он считает что "ядро финансируется хорошо"?Вот мне кажется что кОтОстрофическое недофинансирование.
"Несмотря на поддержку корпораций большинство участников разработки ядра действуют ради интереса в качестве добровольцев - за свою работу оплату получает лишь около 200 разработчиков из более 2000 активных участников разработки."
А потом сроки поддержки LTS-ядер Linux получаем.
(из новости opennet.ru/opennews/art.shtml?num=59791)> Что Вы увидели плохого в том, что Linux Foundation получает финансирование в
> десятки раз большее, чем необходимо для разработки Linux Kernel?Это утверждение верно, если предположить, что сколько тратится на ядро - как раз то, что необходимо для разработки Linux Kernel. А вот это совсем не факт.
> А вы считаете что хорошо финансируется?У меня есть все основания считать, сто это так. А вот что именно привело Вас к мысли об обратном, Вы написать забыли.
> Может еще и цитату Торвальдса приведете, где он считает что "ядро финансируется
> хорошо"?Сказать и написать можно что угодно. А опираясь на факты можно увидеть, что если до 2016 года включительно Торвальдс вкладывал в разработку ядра то миллион, то полтора, то с 2017 года прекратил этим заниматься за ненадобностью.
> Вот мне кажется что кОтОстрофическое недофинансирование.
> за свою работу оплату получает лишь
> около 200 разработчиков из более 2000 активных участников разработки."Значит или не хотят посвящать все свое рабочее время разработке ядра, или не могут. Вы что, за каждый PR в open source проект деньги просите? )))
> А потом сроки поддержки LTS-ядер Linux получаем.
Вы слишком увлеклись демагогией, проигнорировав в новости целый ряд объективных причин, не имеющих никакого отношения к финансированию.
И тем более увлеклись демагогией подменяя тему. $400 тыс. в год на финансирование rustc и stdlib - это вообще ни о чем. Что наглядно демонстрирует отношение enterprise к Rust Foundation и его токсичному community.
P.S. Рекомендую избегать эмоциональных оценок в технических дискуссиях, так как это тоже явный признак демагогии.
А можно чуть раскрыть тему для нубов в расте?
Растоводы кричат что всё пучком.
> Растоводы кричат что всё пучкомВоут, мерзавцы! Все медленно, гарантий нет, бинари жирные, синтаксис вырвиглазный, неподдерживаемое, абыр, АБЫРВАЛГ111
В конце пошёл чистый кодинг на расте
> А можно чуть раскрыть тему для нубов в расте?
> Растоводы кричат что всё пучком.Ну, обычная методичка местных военов против раста.
Типа "жирные бинари", "жирный, обязательный рантайм" и прочего.У них даже получалось хелловорлды на расте собирать чуть ли не на десяток МБ, что конечно же служит самым веским доказательством их̵ ̵к̵р̵и̵в̵ы̵х̵ ̵р̵у̵к̵ их тезисов.
А когда кто-то из мерзких растаманов тыкнет их носом в минимальный хелловрот меньше 1КБ и предложит поискать там рантайм и "жир", можно заявить, что это враки и несчитается и вообще, на си/асме можно еще меньше написать (правда, демонстрировать это военам некогда, им дальше супротив раста воевать надо).
> А когда кто-то из мерзких растаманов тыкнет их носом в минимальный хелловрот
> меньше 1КБ и предложит поискать там рантаймRuntime в этом случае будет прибит гвоздями к конкретной версии rustc. В случае проприетарных приложений, скомпилированных каждое своей версией rustc (включая порой nightly), этих libstd-*.so по 13МБ потребуется десятки. Ладно бы ещё они только на диске место занимали, так ведь они в оперативку грузятся.
>> А когда кто-то из мерзких растаманов тыкнет их носом в минимальный хелловрот
>> меньше 1КБ и предложит поискать там рантайм
> Runtime в этом случае будет прибит гвоздями к конкретной версии rustc.Не-не, в тех демках, как бэ, весь цимес в том, что рантайма - нема, да и ldd выдаст ф̶и̶г̶у̶ "not a dynamic executable". Но да, частично в коде будет "закат солнца вручную", как впрочем и везде ...
> В случае проприетарных приложений, скомпилированных каждое своей версией COMPILERNAME по SOME_SIZE МБ потребуется десятки. Ладно бы ещё
> они только на диске место занимали, так ведь они в оперативку грузятся.Пофиксил, не благодари. MSVCRT рантаймы так же передают приветы.
О стат. линковке (привет гошникам) не заикаемся.
> Не-не, в тех демках, как бэ, весь цимес в том, что рантайма - немаВы про no-std для МК? Это тут при чём? Для реальных проектов не на MK no-std никак не пригоден.
> Растоводы кричат что всё пучком.Просто нет на них Дмитрия Пучкова.
https://www.opennet.dev/openforum/vsluhforumID3/137467.html#310 после этого поста через один было разъяснение, мордеры удалили.Раст не может дать гарантии безопасности, стабильности при исполнении и не имеет верифицируемость кода.
C, C++ может дать гарантии безопасности при исполнении (проактивная защита CPU и ядро OS) в ущерб гарантиям стабильности в виду отсутствия формальной математической верификации кода.
> Раст не может дать гарантии безопасности, стабильности при исполнении и не имеет
> верифицируемость кода.Громкое заявление.
А как же гарантии и проверки на этапе компиляции?
Которые проверят, что при исполнении не нарушится ownership и лайфтаймы.> C, C++ может дать гарантии безопасности при исполнении (проактивная защита CPU и ядро OS) в ущерб гарантиям стабильности в виду отсутствия формальной математической верификации кода.
Т.е они вообще без средств ОС не дают никаких гарантий?
Звучит весьма буллщитно.
В C, C++ гарантии безопасности не даются только одним компилятором. Хотя сегодня компиляторы C, C++ делают очень много для получения безопасного и стабильного бинаря.В C, C++ гарантии безопасности даются всей системой в целом и в ущерб гарантиям стабильности: https://www.opennet.dev/openforum/vsluhforumID3/137467.html#58
Ржавый не даёт общих гарантий безопасности во время исполнения, частные случаи. Проверки во время компиляции могут в некой степени уменьшать или ликвидировать некие популярные дыры, как и в C, C++. Гарантий стабильности ржавый также не даёт. Верифицируемости кода ржавый не имеет. В целом мое мнение о переписывании кода на ржавом кем-то задумано, как заговор с целью притормозить развитие СПО. Напоминает переписывания с питон 2 на 3 которое на пару лет притормозило динамичное развитие питона.
> Раст не может дать гарантии безопасности
> C, C++ может дать гарантии безопасности при исполнении (проактивная защита CPU и ядро OS)То есть "проактивная защита CPU и ядро OS" гарантированно защищают программы, написанные на C и C++, но не защищают написанные на Расте. Я все правильно понял?
Проактивная защита CPU + ядро OS дадут гарантии безопасности и корректности работы с памятью сразу для всех программ на всех языках программирования, включая ржавого. Но за это придется заплатить отсутствием гарантий стабильности при использовании проективной защиты.Если C, C++ прога имеет дыру и кто-то напишет экспорт, то при запуске этого экспорта проактивная защита убьет процесс - отсутствие гарантий стабильности.
Если прога на ржавом, абсолютно корректно работает с памятью, дыр не имеет, эксплоитов не цепляет, то проактивная защита ее убивать не будет. Но в С дыр нашли много, там не только переполнение буфера. Все ли позатыкали в ржавом не знаю. Надо тестить ржавого с проективной защитой!
C, C++, Assembler, Foltran, Pascal (fpc) - с проективной защитой работают хорошо. Pascal имеет проверки памяти на этапе компиляции, но этого мало чтобы получить гарантии стабильности при проективной защите.
Флаги безопасности не сильно роняют производительность, там проценты, в парах есть. Флаги оптимизации поднимут производительность так, что общая выйдет в плюсе.Есть пару пакетов с USE флагами: pic -asm которые вырежут пока плохо написанную асемблерную оптимизацию SIMD инструкциями. Вот для этих пару пакетов производительность может упасть заметно, надо иметь ввиду и тестировать:
app-arch/gzip
app-arch/lrzip-next
dev-libs/libsecp256k1
net-p2p/bitcoin-core
Потому что си не умеет безопасно работать с памятью!
Как и ассемблер...
Ассемблер - это низкоуровневый язык, там это не так зашкварно.
А СИ - ассемблер, где наборы ассемблерных мнемоник просто заменены операторами с автоподстановкой подходящего регистра. Потому трансляторы С->АСМ такие простые и быстрые.
значит я могу смело в резюме писать что умею на ассемблере?
Если вы — транслятор.
> Потому что си не умеет безопасно работать с памятью!Потому что это просто кроссплатформенный ассемблер, который был создан для ускорение портирования юникса и прочего софта с PDP-11 на "более новые" машины.
А размер всего юникса того времени был около 100кLOC, что на порядки меньше размеров современных программ (ядро линя - 40MLOC)Но, из-за простоты сишки, отсутствия необходимости думать и того, что на ней писать начать может даже обезьяна, сишка стала ПХП своего времени и вытеснила другие нормальные языки.
Результаты чего мы наблюдаем даже через 50 лет.
> юникса и прочего софта с PDP-11 на "более новые" машины.
> А размер всего юникса того времени был около 100кLOC,100кLOC, это уже V7. Меньше:
PDP-7
https://github.com/dspinellis/unix-history-repo/tree/Researc...
Language Files Lines Code Comments Blanks
===============================================================================
GNU Style Assembly 36 11599 11378 0 221
V5
https://github.com/dspinellis/unix-history-repo/tree/Researc...
Language Files Lines Code Comments Blanks
===============================================================================
GNU Style Assembly 207 33538 31463 58 2017
C 122 27429 24006 1018 2405
C Header 13 418 357 34 27
V7
https://github.com/dspinellis/unix-history-repo/tree/Researc...
Language Files Lines Code Comments Blanks
===============================================================================
GNU Style Assembly 129 19982 18433 2 1547
C 862 157003 134476 8122 14405
C Header 109 6572 5111 838 623
BSD-1
https://github.com/dspinellis/unix-history-repo/tree/BSD-1
Language Files Lines Code Comments Blanks
===============================================================================
GNU Style Assembly 56 5799 5655 1 143
C 316 55378 43588 7694 4096
C Header 29 4018 2580 1089 349
это не молоток не может забивать гвозди и отбивает пальцы, а криворукий, держащий этот молоток :)
Ты не поверишь, но даже к молотку есть требования)
Что-то типа:
"Слесарные молотки, кувалды должны иметь ровную, слегка выпуклую поверхность бойковой части и быть надежно насажены на рукоятки."Т.е если какой-то производитель выпустит молоток, который раз в год ̶с̶т̶р̶е̶л̶я̶е̶т̶ ̶в̶ ̶н̶о̶г̶у̶ слетает с ручки прямо в лоб, то таким куском кала пользоваться нельзя.
Более того, есть даже правила для ̶д̶о̶б̶а̶в̶л̶е̶н̶и̶я̶ ̶п̶р̶о̶в̶е̶р̶о̶к̶ ̶и̶ ̶с̶а̶н̶и̶т̶а̶й̶з̶е̶р̶о̶в̶ защиты:
"При работах инструментами ударного действия работники должны пользоваться защитными очками для предотвращения попадания в глаза отлетающих твердых частиц."Так что иди учи уроки, а потом придумай более хорошую аналогию)
> Ты не поверишь, но даже к молотку есть требования)
> Что-то типа:
> "Слесарные молотки, кувалды должны иметь ровную, слегка выпуклую поверхность бойковой
> части и быть надежно насажены на рукоятки."Ну и как эти требования отменяют факт попадания молотком по пальцу? Даже бумажным молотком мы попадем по пальцу при условии криворукости нашей, а не из-за того, что молоток бумажный, а не резиновый.
> Т.е если какой-то производитель выпустит молоток, который раз в год ̶с̶т̶р̶е̶л̶я̶е̶т̶
> ̶в̶ ̶н̶о̶г̶у̶ слетает с ручки прямо в лоб, то таким
> куском кала пользоваться нельзя.Ну это ведь требования ко всем молоткам относится, то что вам по лбу ударит резиновый за место железного, не отменяет факта попадания по лбу. Это ведь следствие вашей же криворукости, а не несоблюдение требований каких-то.
> Более того, есть даже правила для ̶д̶о̶б̶а̶в̶л̶е̶н̶и̶я̶
> ̶п̶р̶о̶в̶е̶р̶о̶к̶ ̶и̶ ̶с̶а̶н̶и̶т̶а̶й̶з̶е̶р̶о̶в̶
> защиты:
> "При работах инструментами ударного действия работники должны пользоваться защитными
> очками для предотвращения попадания в глаза отлетающих твердых частиц."В список этих требований еще должны входить всякие требования на гвозди по ударопрочности и т.д. и контроль самого удара ведь, если вы замахнетесь с "такой силой" (большой), что гвоздь разлетится на куски, то это опять таки ваша КРИВОРУКОСТЬ ведь, вы не можете контролировать свою силу удара, не так ли?
> Так что иди учи уроки, а потом придумай более хорошую аналогию)
Советую вам писать на "вы", ибо бот обращения на "ты" считает за оскорбления :)
> Ну и как эти требования отменяют факт попадания молотком по пальцу?А при чем тут палец?
Вы тут RCE с пальце не сравнивайте)СИшные проблемы вызывают не "я себе пальчик ударил", а "оторвало ногу".
> Ну это ведь требования ко всем молоткам относится, то что вам по лбу ударит резиновый за место железного, не отменяет факта попадания по лбу.
Последствия)
От резиновго будет шишка, а от железного можно и ноги протянуть.> Это ведь следствие вашей же криворукости, а не несоблюдение требований каких-то.
Если голова молотка закреплена плохо по ТУ производителя - то это просто овняный инструмент.
Примерно как СИшка с ее УБ.> В список этих требований еще должны входить всякие требования на гвозди по ударопрочности и т.д. и контроль самого удара ведь, если вы замахнетесь с "такой силой" (большой), что гвоздь разлетится на куски, то это опять таки ваша КРИВОРУКОСТЬ ведь, вы не можете контролировать свою силу удара, не так ли?
Нет не должны.
Тк гвоздь это расходник, то производители расходников должны озаботиться совместимостью.
Более того, на гозди есть целая серия ГОСТов, которые регламетрируют в том числе прочность.И вообще попытка свести все на "ваша КРИВОРУКОСТЬ" звучит уныло.
В куче отраслей всякие ТБ штуки являются обязательными и никто не будет рассказывать "петровича на вал накрутило не потому что у нас кожух станка убрали, а потому что криворукий", "от васи осталась горстка пепла не потому что он поленился взять изолирующий ковер, а потому что криворукость".
Дла программинга с его ASS IS стандартов почти нет, но ситуация меняется.
> Советую вам писать на "вы", ибо бот обращения на "ты" считает за оскорбления :)Ого, это что-то новое.
> А при чем тут палец?
> Вы тут RCE с пальце не сравнивайте)
> СИшные проблемы вызывают не "я себе пальчик ударил", а "оторвало ногу".Ну это зависит от оценки ущерба (урона, болевой порог и т.д.), в моем посыле это не важно, что удар по пальцу, что по лбу - равносильный урон, больно в любом случае. Я даже не отрицаю случая, что вам даже не будет больно от удара по пальцу, когда вы лишены болевых чувств. Но это не отеняет факта криворукости, а оно определяется именно попаданием молотом по всему (палец, лоб, ногу и т.д.), но не по прямому назначению - гвоздю.
> Последствия)
> От резиновго будет шишка, а от железного можно и ноги протянуть.То есть, предлагаете забивать гвозди бумажным молотом? Мы же за криворукость говорим, ведь не последствия (боль) определяет криворукость, не "материал" молота, а именно те действия которые приводят к попаданию по пальцу (выше дано определение криворукости).
> Если голова молотка закреплена плохо по ТУ производителя - то это просто
> овняный инструмент.
> Примерно как СИшка с ее УБ.УБ определены в стандарте и отдается на волю компилятора. Все вопросы к компилятору, а не к языку. Можете привести пример формально корректного алгоритма с УБ?
> Нет не должны.
> Тк гвоздь это расходник, то производители расходников должны озаботиться совместимостью.Какой расходник? Это вам не масло (которое кстати тоже подчиняется всяким требованиям), которое надо заменять после отработки ресурса. И в случае сварки электроды - не расходник, а прямое назначение. Может вам производят бумажные гвозди, которые необходимо забивать железным молотом?
> Более того, на гозди есть целая серия ГОСТов, которые регламетрируют в том
> числе прочность.Ну ударьте с большей силой по гвоздю он разлетится на куски, это разве не криворукость людская, которая не контролирует силу удара?
> И вообще попытка свести все на "ваша КРИВОРУКОСТЬ" звучит уныло.
Ток аргументы ваши так же звучат уныло.
Ударять молотом по пальцу - следствие КРИВОРУКОСТИ!
> "петровича на вал накрутило не потому что у нас кожух станка убрали, а потому что криворукий"
Все именно так и есть, потому-что он КРИВОРУКИЙ, да еще и глаза залил и не увидел, что кожух скомуниздил его собутыльник.
> Дла программинга с его ASS IS стандартов почти нет, но ситуация меняется.
Ну вот поэтому и даже от кода на расте ничего хорошего при тотальной криворукости ожидать не стоит.
> Ого, это что-то новое.
Ну комент скринит ASKBOT как я понял из-за этого, когда он видит обращение на "ты" и видать думает, что кто-то кого-то пытается оскорбить :) Могу ошибаться.
> УБ определены в стандарте и отдается на волю компилятора. Все вопросы к компилятору, а не к языку. Можете привести пример формально корректного алгоритма с УБ?Только после того как мне показжут язык без компилятора)
>> "петровича на вал накрутило не потому что у нас кожух станка убрали, а потому что криворукий"
> Все именно так и есть, потому-что он КРИВОРУКИЙ, да еще и глаза залил и не увидел, что кожух скомуниздил его собутыльник.Отлично, а теперь усложним мысленный эксперимент.
Пусть на станке не было кожуха никогда.
Вот его производителю было плевать - ̶б̶а̶б̶ы̶ ̶н̶а̶р̶о̶ж̶а̶ю̶т̶ петровичи - они ж расходники.
Является это инструмент хорошим?Ну или какая-то копейка где нет даже ремней безопасности. Является ли это автомобилем или ведром с гайками?
Двойная изоляция в электроинструменте появилась не просто так и стала стандартом.
> Ну вот поэтому и даже от кода на расте ничего хорошего при тотальной криворукости ожидать не стоит.
У андроидщиков пока все получается.
Они даже писали что ошибок по памяти в раст коде за год (ЕМНИП) у них не было ни одной.> Ну комент скринит ASKBOT как я понял из-за этого, когда он видит обращение на "ты" и видать думает, что кто-то кого-то пытается оскорбить
> :) Могу ошибаться.Мне казалось что ASKBOT это когда кто-то жмакает "сообщить модератору" 🤔
Но тоже могу ошибаться)
> Только после того как мне показжут язык без компилятора)А с чего вы сделали такой вывод? Компилятор следует стандарту языка, язык без компилятора существует, а вот компилятора без языка - нет :) Мне не нужен коредуб, чтобы исполнить какой-нибудь алгоритм, достаточно терминов машины Тьюринга.
Язык один, а компиляторов может быть много.
> Отлично, а теперь усложним мысленный эксперимент.
> Пусть на станке не было кожуха никогда.
> Вот его производителю было плевать - ̶б̶а̶б̶ы̶ ̶н̶а̶р̶о̶ж̶а̶ю̶т̶
> петровичи - они ж расходники.
> Является это инструмент хорошим?Если в его инструкции по применению написано "пальцы и другие части тела в данную область не совать", то можно сказать - хороший инструмент. Вопрос в другом, должны ли быть описаны все случаи жизни в этой инструкции? К примеру, в инструкции к применению ядерной бомбы написано - "Не прикуривать" :) Думаю инструкции на все случаи жизни должны быть описаны в стандартах по производству этих инструментов, но а кто перечислил все эти случаи жизни? Говорить, что отныне все компиляторы языков должны автоматически управлять памятью, было бы отлично, но какова цена этого?
> Ну или какая-то копейка где нет даже ремней безопасности. Является ли это
> автомобилем или ведром с гайками?Это автомобиль по задумке, и по стандартам - отрицать это бред. А по каким стандартам это уже разговор из другой серии.
> Двойная изоляция в электроинструменте появилась не просто так и стала стандартом.
Почему до сих пор электричество убивает? Почему не придумать стандарт электричества, которое не убивает? Мы должны придумывать стандарты розеток куда нет физ. возможности сунуть пальцы? Или от короткого замыкания перестало происходить возгорание и как следствие - пожары.
> У андроидщиков пока все получается.
> Они даже писали что ошибок по памяти в раст коде за год
> (ЕМНИП) у них не было ни одной.также говорят и пхпешники, которые понятие не имеют, что такое память.
> Мне казалось что ASKBOT это когда кто-то жмакает "сообщить модератору" 🤔
> Но тоже могу ошибаться)а возможно, я совсем забыл, что нахожусь в среде где "товарищмайор,разрешитедоложить" это ген :)
Молоток виноват в том, что не распознаёт объект, по которому бьёт и мгновенно не меняет материал бойка: от комка ваты, если там палец, до нейтринного уберкомпактного освинцованного слитка, если это гвоздь.Именно поэтому я смотрю уже три года на все эти споры си-раст-<баззвордязык>, как на битву слабоумных, рассуждающих, что тёплое лучше мягкого потому, что оно зелёное, но в крапинку и кузявее сладкого, но в форме перца с запахом апельсина.
Покажи пряморуких сишников, которые не ошибаются в работе с памятью. Очень интересно.
> Покажи пряморуких сишников, которые не ошибаются в работе с памятью.Я всю жизнь пишу на голых указателях - и никогда проблем не было. Зуб даю!
> Я всю жизнь пишу на голых указателях - и никогда проблем не было. Зуб даю!И много у тебя их осталось?))
> И много у тебя их осталось?))А много их у тех, кто "грызет гранит науки"? Вот когда вы попробуете "погрызть гранит Си", у вас будет ровно столько "зубов".
У нас как у орков в вахе они сами растут) Поэтому и топим за С
> Покажи пряморуких сишниковну как показать вам код, который под NDA? Хотя тут надо отвечать вопросом на вопрос, к примеру - "покажи мне код работы с памятью где каждый сишник допустит ошибку (своего рода палающий баг)", но в таком случае баг даже не в работе с памятью, а в архитектуре алгоритма, которая допускает эту "плавучесть", но даже если это одно единственное исключение (исключительная ситуация), всегда можно его отдельно обработать.
Так что, при прямых руках и камнем можно забить гвоздь и микроскопом, не отбив пальца.
> "покажи мне код работы с памятью где каждый сишник допустит ошибку"Так проблема в том, что каждый сишник ошибается немного в другом месте.
А результат один и тот же.> ну как показать вам код, который под NDA?
Мы регулярно наблюдаем дыры и взломы проприетарных продуктов с использование buffer overflow, int overflow, double free и так далее.
Достаточно пройтись по тегу pwn2own (opennet.ru/keywords/pwn2own.html) и там будет просто море примеров.Из последнего (opennet.ru/opennews/art.shtml?num=63254)
VMware ESXi: 2 успешные атаки, позволившие выполнить код на стороне хост-окружения. Проблемы вызваны целочисленным переполнением и использованием неинициализированных переменных.VMware Workstation: Одна успешная атака, позволившая выполнить код на стороне хост-окружения. Проблема вызвана переполнением буфера.
Windows 11: 5 успешных атак, позволивших выполнить код с правами SYSTEM. Уязвимости вызваны обращением к памяти после освобождения, целочисленным переполнением, переполнением буфера, неправильной обработкой типов (Type Confusion) и состоянием гонки.
А таких проблем тыщщи. По остальным ссылкам можешь пройтись сам.
Типичные проблемы си и плюсов, несущих родовую травму сишки.
> Так проблема в том, что каждый сишник ошибается немного в другом месте.
> А результат один и тот же.Результат некорректного алгоритма - очевиден, и ошибка с памятью это формально некорректный алгоритм. В формально корректном алгоритме по определению нет ошибки, тем более с памятью.
> Мы регулярно наблюдаем дыры и взломы проприетарных продуктов с использование buffer overflow,
> int overflow, double free и так далее.Ну это говорит только о криворукости не более, кто-нибудь приведет мне пример алгоритма, который всегда будет содержать "int overflow, double free и так далее"? Нет? так в чем дело в Си? На Си нельзя писать формально корректные алгоритмы?
> А таких проблем тыщщи. По остальным ссылкам можешь пройтись сам.
> Типичные проблемы си и плюсов, несущих родовую травму сишки.Мы же не пытаемся отрастить руки у от рождения безруких инвалидов, так ведь? Мы пытаемся их приспособить - протезирование и т.д. Но тем не менее даже в таком случае мы разве должны требовать от них умение жонглирования? Думаю, нет, не логично ибо они ограниченны.
Отсюда, если вы всякий раз Сишкой стреляете себе в ногу, то вам не Сишку менять надо на раст, а стоит задуматься над тем, стоит ли заниматься тем где вы ограниченны.
> ошибка с памятью это формально некорректный алгоритмТочно? Или может это проблема в конкретной реализации конкретного алгоритма?
> Ну это говорит только о криворукости не более,
Проблема в то, что пряморуких сишников не существует.
Даже диды-аксакАлы, которые пишут в ядро с 1991 года, допускают такие ошибки.> На Си нельзя писать формально корректные алгоритмы?
На си нельзя два числа сложить чтобы не получить UB))
> Мы же не пытаемся отрастить руки у от рождения безруких инвалидов
А мне нравится ваше сравнение сишников с безрукими инвалидами. Но осторожней, кому-то оно может показаться оскорбительным.
> Отсюда, если вы всякий раз Сишкой стреляете себе в ногу,
Я себе в ногу не стреляю - я на этом слава богу вообще не пишу.
Зато наблюдаю, как с завидной регулярность стреляют другие.
И иногда мне отстреливает ногу просто рикошетом.Кстати, раз вы начали про стрельбу - как вы думаете, почему требование наличия предохранителя стало законодательным, а не "по желанию производителя", а в тот же глок добавили аж три предохранителя - trigger safety, firing pin safety и drop safety?
Как раз для того, чтобы из-за дефектности изделия не пострадали случайные мимокрокодилы.Вот у тут будет так же - 6ыdlокодеры на недоязычке так и не научатся писать без багов с памятью за 40+ лет и из законодательно заставят на нем перестать писать.
ЕС и штаты уже идут в этом направлении. Жаль что бюрократия вещь не быстрая.
>> ошибка с памятью это формально некорректный алгоритм
> Точно? Или может это проблема в конкретной реализации конкретного алгоритма?А вы как формально описали память? Выход за границу у вас также формально должен быть описан, и случаи его обработки и т.д. И в итоге у вас и будет формально корректный алгоритм. А реализация - дело техники, хоть на машине Тьюринга, хоть на коредуба, неважно.
> Проблема в то, что пряморуких сишников не существует.
> Даже диды-аксакАлы, которые пишут в ядро с 1991 года, допускают такие ошибки.Ну как и тех, кто в руках держал молот и ни разу по пальцу не попал. Но это не отменяет того факта, что молотом можно бить по гвоздю и не попадать по пальцу, для этого достаточно быть ПРЯМОРУКИМ!
> На си нельзя два числа сложить чтобы не получить UB))
Это к компилятору, а не к языку.
> А мне нравится ваше сравнение сишников с безрукими инвалидами. Но осторожней, кому-то
> оно может показаться оскорбительным.С коих пор инвалид это оскорбление? Человек ограничен в чем-то и для какой-то работы он по факту инвалид, тут ничего оскорбительного нет. Зачем "заставлять" (байтить) безрукого или с протезами жонглировать? Хочет - пусть жонглирует, но требовать от него это делать как делают профи - маразм! Я не запрещаю криворуким писать на Си, пишите ради Бога. В этом то и суть отличия профи от инвалида (ограниченного в возможностях, способностях), и там где необходимо работа профи - должен работать профи, от этого инвалид оскорбляться не должен, а должен понимать свои ограничения и держаться подальше.
> Я себе в ногу не стреляю - я на этом слава богу
> вообще не пишу.
> Зато наблюдаю, как с завидной регулярность стреляют другие.
> И иногда мне отстреливает ногу просто рикошетом.Если вы не профи в грибах и пытаетесь съесть каждый найденный в лесу гриб, то какова вероятность вашего отравления? Такая же аналогия с саперным делом, одна ошибка ценой в жизнь. Какой результат будет от не профи в этой области?
> Кстати, раз вы начали про стрельбу - как вы думаете, почему требование
> наличия предохранителя стало законодательным, а не "по желанию производителя", а в
> тот же глок добавили аж три предохранителя - trigger safety, firing
> pin safety и drop safety?
> Как раз для того, чтобы из-за дефектности изделия не пострадали случайные мимокрокодилы.Стоп, дефективность изделия - отдельная тема контроля качества (дефектный молот (из сталь другой марки) не обязан всегда по пальцу ударять). В вашем примере предохранитель нужен от случайного выстрела, который по большей части происходил когда тупо оружие роняли из рук на пол. Ну это разве не криворукость на лицо? Ровно поэтому там и скоба есть, прикрывающая спусковой крючок:)
> Вот у тут будет так же - 6ыdlокодеры на недоязычке так и
> не научатся писать без багов с памятью за 40+ лет и
> из законодательно заставят на нем перестать писать.
> ЕС и штаты уже идут в этом направлении. Жаль что бюрократия вещь
> не быстрая.Людское законодательство - маразм, они вам завтра запретят вообще что-либо писать. Ну как при Екатерине:
"""
О бытiи помѣщичьимъ людямъ и крестьянамъ въ повиновенiи и послушанiи у своихъ помѣщиковъ, и о неподаванiи челобитенъ въ собственныя Ея Величества руки.
"""//ru.wikipedia.org/wiki/Крепостное_право_в_России
> для этого достаточно быть ПРЯМОРУКИМ!Вот в том то и проблема. Нет пряморуких сишников! Вот просто нет и все))
> Это к компилятору, а не к языку.
Нет, именно к языку. Который в недостандарте под названием ISO/IEC 9899 объявил, что signed integer overflow это undefined behavior.
Не unspecified behavior, не implementation-defined behavior, а именно undefined, с которым программа теряет Conformance и компилятор может преобразовать этот код во что угодно.ISO/IEC 9899, пункт 3.4.3
EXAMPLE An example of undefined behavior is the behavior on integer overflowИ это только одно из 193 UB в С99 (gist.github.com/Earnestly/7c903f481ff9d29a3dd1)
Стандарт сишки - овно, просто defective by design. Очевидно почему так произошло, если посмотреть на даты стандартизации и создания сишки, но это не оправдание.Не знаю почему на него так яростно наяривают апологеты сишки, наверное просто больше не на что. Сам создатель сишки Денис Ритчи писал про "стандартизацию":
-- 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. --> Стоп, дефективность изделия - отдельная тема контроля качества
Нет, сишки дефектна начиная со стандарта. Она до сих пор застряла в 70х.
Ее уже не исправишь, лучше сразу закопать.> Людское законодательство - маразм
Беззаконие или закон божий лучше?))
> Вот в том то и проблема. Нет пряморуких сишников! Вот просто нет
> и все))Если сишник всю жизнь писал хелловроты он пряморукий?
> Нет, именно к языку. Который в недостандарте под названием ISO/IEC 9899 объявил,
> что signed integer overflow это undefined behavior.
> программа теряет Conformance и компилятор может преобразовать этот код во что
> угодно.Так в чем проблема, в вашем компиляторе? Он не дал вам никаких средств обработки этих ситуаций? Язык то причем? Или там где происходит "signed integer overflow" это непредсказуемая и не решаемая проблема, как проблема останова? Язык говорит - решай как знаешь, в чем проблема? Вы хотели, чтобы там написано было - "делай так и никак иначе"?
> Не знаю почему на него так яростно наяривают апологеты сишки, наверное просто
> больше не на что. Сам создатель сишки Денис Ритчи писал про
> "стандартизацию":
> -- 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. --Ну так все ваши претензии это претензии к компилятору. Стандарт не требует ничего невозможного, на что можно было бы сослаться и сказать - это что за язык такой, "язык сломаешь пока выговоришь", тип такого.
> Нет, сишки дефектна начиная со стандарта. Она до сих пор застряла в
> 70х.
> Ее уже не исправишь, лучше сразу закопать.Ну вот давайте конкретно исправим "signed integer overflow", что мы должны записать в стандарте?
>> Людское законодательство - маразм
> Беззаконие или закон божий лучше?))А кто-то уже законы природы отменил? Беззакония по определению нет, если принять за аксиому детерминизм всего бытия.
> Если сишник всю жизнь писал хелловроты он пряморукий?Нет, он просто еще не показал свою криворукость))
> Язык то причем?
При том, что это в "стандарте" языка есть UB, а не в компиляторе.
> Язык говорит - решай как знаешь
Неа, "решай как знаешь" это implementation defined, а не UB.
А UB - это "x** его знает как оно должно быть, мы договориться не смогли, давайте просто не делайте так."Наличие UB вообще делает ваш код "невалидным" и компилятор имеет полное право просто его удалить. То что всякие gcc/clang налепили костылей чтобы результаты жизнедеятельности погромистов можно было хоть как-то скомпилить... ну так это как раз workaround дефективного стандарта.
> Стандарт не требует ничего невозможного
"Стандарт" не выполняет свою функцию - однозначного определения поведения.
> Ну вот давайте конкретно исправим "signed integer overflow",
> что мы должны записать в стандарте?Записать однозначное поведение в виде "two's complement wrapping".
А если нужно что-то другое - то вызывать соответствующие функции (checked, overflowing, saturating и тд). И оно гарантировано будет работать всегда одинаково на всех платформах!Но в теории можно и что-то другое. Главное чтобы оно было ЯВНО прописано в стандарте.
> А кто-то уже законы природы отменил?
"Закон природы" это твой сосед тебя убил и забрал твою жену. Просто потому что сильнее.
> При том, что это в "стандарте" языка есть UB, а не в компиляторе.И что? написано ведь "решай как знаешь".
> Неа, "решай как знаешь" это implementation defined, а не UB.
> А UB - это "x** его знает как оно должно быть, мы договориться не смогли, давайте просто не делайте так.""решай как знаешь" это и есть ""x** его знает как оно должно быть", поэтому ответственность переложили на компилятор, "решай и делай сам, как хочешь". Если бы писаки стандарта пришли бы к какому-то мнению как это разрешить, то они предложили бы и это было бы вовсе не UB как вы заметили. А почему они не предложили, на то есть конкретные причины, надо спросить у писак стандарта.
А "implementation defined" - это "делай как хочешь".
> Наличие UB вообще делает ваш код "невалидным" и компилятор имеет полное право просто его удалить.
UB часть стандарта, и разрешения этой ситуации стандарт переложил на плечи компилятора.
> "Стандарт" не выполняет свою функцию - однозначного определения поведения.
Стандарт это формальность, ни один компилятор не обязан строго следовать стандарту.
> Записать однозначное поведение в виде "two's complement wrapping".
> А если нужно что-то другое - то вызывать соответствующие функции (checked, overflowing, saturating и тд). И оно гарантировано будет работать всегда одинаково на всех платформах!Стандарт не обязан это описывать если это тупо решается средствами языка.
> Но в теории можно и что-то другое. Главное чтобы оно было ЯВНО прописано в стандарте.
На все есть причины, в стандарте если не описаны какие-либо проверки на выходы за границы, это не означает, что их невозможно предотвратить средствами самого языка.
> "Закон природы" это твой сосед тебя убил и забрал твою жену. Просто потому что сильнее.
кто-то ему может это запретить сделать? А его сосед придет и поступит с ним также, в чем проблема? Природа существует в балансе, нет такого "паразита", который может уничтожить всю природу и т.д. И ни одно существо не способно нарушить этот баланс, то есть законы природы.
> Стандарт это формальность, ни один компилятор не обязан строго следовать стандарту.Ахаха! Бл.... Прям в "Фонд золотых цитат сишников"!
А нафига нужен такой стандарт, который "формальность"?
У нас есть стандарт "для колбасы", но производитель "не обязан строго следовать стандарту", поэтому туда можно добавлять туалетную бумагу, мел, крыс, да?))> в стандарте если не описаны какие-либо проверки на выходы за границы,
> это не означает, что их невозможно предотвратить средствами самого языка.Кажется ты не понимаешь.
Когда компилятор "видит" UB, то для него это "невозможный" код.
Он может его просто выбросить и заменить на no-op.Вот у АДА Спарк нормальный стандарт. Там не только нет UB, но и для того, чтобы называть себя "компилятор языка Ада" нужно пройти проверку на тестовых данных.
А для сишки любой кал может назваться "компилятором си".
Но на аде писать было сложно, а и 6ыdloкодеры выбрали сишечку.
> У нас есть стандарт "для колбасы", но производитель "не обязан строго следовать стандарту", поэтому туда можно добавлять туалетную бумагу, мел, крыс, да?))если потребитель это схавает, то допустимо. Иначе он (потребитель) должен проверить на соответствие этим стандартам, стандарты без проверки - "вилами по воде".
> Когда компилятор "видит" UB, то для него это "невозможный" код.
Отлично, остановись моя программа, в чем проблема?
> Он может его просто выбросить и заменить на no-op.
Да ради Бога, замени хоть на хеловрот, в чем проблема? Стандарт вам говорит "решай как хочешь", компилятор "решает" как хочет, так в чем проблема? Проблема в том, что это не совсем то, что вы "хотите"? Так кого это должно волновать то?
> А для сишки любой кал может назваться "компилятором си".
если реализует язык по описанному стандарту, в чем проблема?
> Но на аде писать было сложно, а и 6ыdloкодеры выбрали сишечку.
"Преступление и наказание" шедевр не от того, что написана на русском языке!
> Мы же не пытаемся отрастить руки у от рождения безруких инвалидов, так ведь?Видишь ли, безрукие не проходят естественный отбор в силу того, что рукастые получают над ними конкурентное преимущество. И с вашей Сишочкой происходит буквально то же самое: еще в начале нулевых она вымерла во всех областях, кроме древнего легаси и embedded, а теперь и в них она окончательно добивается Растом.
> Видишь ли, безрукие не проходят естественный отбор в силу того, что рукастые
> получают над ними конкурентное преимущество.Лишенные рук не лишены мозгов, и могут утереть нос многим двуруким, у них на то мотивации больше. И выживает не сильнейший и могучий, а желающий жить. Люди без ног на двух протезах Эвересты покоряют, но не факт, что Эверест покорит самый здоровый человек. И таких примеров много.
> еще в начале нулевых она вымерла во всехВыходят стандарты, пишут компиляторы, пишут код на Си, совершают все те же ошибки, ну и никак не помрет. Может у вас другое определение процесса вымирания?
> Лишенные рук не лишены мозгов, и могут утереть нос многим двуруким, у них на то мотивации большеА у девчуль больше мотивации заводить пары с двурукими, чем с безрукими. В этом-то и загвоздка, дружок: безрукие могут и Эвересты покорять и т.п., но вот только продолжения рода у них нет хоть тресни.
Так же и Сишочкой: можно на "безруком" языке превозмогать и вопреки здравому смыслу совершать подвиги, а можно просто взять нормальный "двурукий" инструмент и не любить себе мозг.
> Выходят стандарты, пишут компиляторы, пишут код на Си, совершают все те же ошибки, ну и никак не помрет
Ну так я назвал ровно две обоасти, в которых Си пока еще не умер: легаси и встройка (как правило два в одном). Знаете еще хоть одну область, где Си еще жив как основной язык?
> А у девчуль больше мотивации заводить пары с двурукими, чем с безрукими.А безруких девчуль природа уже отменила? Это что-то из серии про "девочки не пукают"?
> В этом-то и загвоздка, дружок: безрукие могут и Эвересты покорять и т.п., но вот только продолжения рода у них нет хоть тресни.
Продолжение рода это есть цель такая?
> Так же и Сишочкой: можно на "безруком" языке превозмогать и вопреки здравому смыслу совершать подвиги, а можно просто взять нормальный "двурукий" инструмент и не любить себе мозг.
Подмена понятий, "безрукий" - человек, а не язык.
> Знаете еще хоть одну область, где Си еще жив как основной язык?
я не знаю, что такое "легаси", дайте определение.
>> Покажи пряморуких сишников
> ну как показать вам код, который под NDA?Он не просил показать код - он просил показать показать пряморуких сишников. А таких в опеннетных комментариях традиционно хоть пруд пруди. 😂
> Он не просил показать код - он просил показать показать пряморуких сишников.
> А таких в опеннетных комментариях традиционно хоть пруд пруди. 😂я вайбкодер, я квадробер :)
Я не могу проверить, действительно ли сишный код под NDA так хорош, так что для меня это из разряда веры, я знаю только, что из открытых проектов на сишке примерно все имеют в анамнезе ошибки работы с памятью.
> Я не могу проверить, действительно ли сишный код под NDA так хорошну а мне как проверить, действительно ли "прямые" руки у программиста?
Твоё мнение насчёт прямоты рук не имеет практического смысла, факт в том, что примерно все сишки не могут писать код без ошибок типа use-after-free, так что если на уровне языка можно избавиться от таких ошибок - это очень здорово.
> что примерно все сишки не могут писать код без ошибок типа use-after-free, так, что если на уровне языка можно избавиться от таких ошибок - это очень здорово.Ну избавились мы от этого и получили что? Раст? Какое средство языка си мешает избавлению от use-after-free? Тупо незнания со стороны программиста устройство памяти и ее контроля, и все! Все кто топит за то, чтобы это все делал за них компилятор - просто не знают как это решать, я другого объяснения не вижу.
> это очень здорово
было бы здорово, когда мне не будет необходимости вообще писать программы, пусть этим неблагодарным делом занимается другая программа, написанная один раз более "умелым" программистом.
> Ну избавились мы от этого и получили что? Раст?Ага, язык нового поколения, который пытается исправить недостатки предыдущего)
> Какое средство языка си мешает избавлению от use-after-free?
Никакое.
> Тупо незнания со стороны программиста устройство памяти и ее контроля, и все! Все кто топит за то, чтобы это все делал за них компилятор - просто не знают как это решать, я другого объяснения не вижу.
А какое может быть решение если 40+ лет пограммисты делают изо дня в день одни и те же глупые ошибки?
> А какое может быть решение если 40+ лет пограммисты делают изо дня в день одни и те же глупые ошибки?я просто не понимаю, зачем вы их называете программистами? это ведь "криворукие" погроммисты.
> Никакое.
не освобождать - религия запрещает?
>> А какое может быть решение если 40+ лет пограммисты делают изо дня в день одни и те же глупые ошибки?
> я просто не понимаю, зачем вы их называете программистами? это ведь "криворукие" погроммисты.А потому что других нет)
В стране одноглазых двуглазый не будет нормой.
Так вот, "норма" для программиста на сишке - это делать ошибки по памяти.
> Так вот, "норма" для программиста на сишке - это делать ошибки по памяти.дураком быть не запретишь, в мире раста я так думаю дураков не существует?
>> Так вот, "норма" для программиста на сишке - это делать ошибки по памяти.
> дураком быть не запретишь, в мире раста я так думаю дураков не существует?Конечно существуют!
Тут вопрос в финальном результате.
Если компилятор надавал по рукам и заставил исправить, в итоге код валидный и нет уязвимостей... то меня это устроит на 100%.
Вам шашечки или ехать? (с)Это нормально, когда инструмент становится не только лучше по качеству, но и защищает от человеческих ошибок.
Вся история Техники Безопасности как раз про это)
> Конечно существуют!
> Вся история Техники Безопасности как раз про это)а всего то надо было просто греть в горне гвозди, а потом их забивать молотом, и по пальцем никогда не попадем, потому-что держать их будем вовсе не руками :)
Я же объяснил логику выше, если ты не понимаешь, почему "ну пусть просто все пишут как надо" не работает, то я ничем помочь не могу.
> "ну пусть просто все пишут как надо"вот именно, что нигде не написано "как надо", и каждый компилятор по своему это все может делать, на что и указывает стандарт.
> Я же объяснил логику выше
А я вам хочу донести лишь одно, все ваши претензии должны быть направлены на конкретный компилятор и на собственную криворукость, а не на язык и его стандарт.
> А я вам хочу донести лишь одно, все ваши претензии должны быть направлены на конкретный компилятор и на собственную криворукость, а не на язык и его стандарт.Вам бы с логикой-то подружиться. Стандарт говорит "делай что хочешь", компиляторы, реализующие С по тому самому стандарту действительно делают что хотят - но виноваты в последствиях пресловутые "ненастоящие сишники". И, главное, Раст не нужен - нужно просто стать настоящим сишником!
Цирк да и только...
> но виноваты в последствиях пресловутые "ненастоящие сишникии судя по вашей логике надо стандарт менять? :) Идите пишите свой компилятор, "настоящий" вы наш, если вас существующие компиляторы не устраивают, а если дойдет дело до переписывания стандарта, то вы будете последний к кому прислушаются (ничего личного).
> И, главное, Раст не нужен - нужно просто стать настоящим сишником!
Не сишником надо быть, а "настоящим".
> Цирк да и только...
Ну конечно, ведь "Войну и мир" может написать, только владеющий русским языком.
> Ну избавились мы от этого и получили что? Раст? Какое средство языка си мешает избавлению от use-after-free?Так как мы уже от проблемы избавились и получили Раст, то и вопрос "как избавиться от use-after-free в С" уже не актуален.
> Так как мы уже от проблемы избавилисьДа одним из способов, переписать весь язык, чтобы получился новый.
> Какое средство языка си мешает избавлению от use-after-free?
А что с этим вопросом?
Эх, сколько телодвижений для исправления того, что ущербно с даты создания.
Зато потом читаем клевую TEH DRAMA комитета по внедрению SafeC++.А ведь достаточно взять простой ржавый...
достаточно взять ржавый и начать писать extern "C" потому что без сишного ABI он никому не нужен
> достаточно взять ржавый и начать писать extern "C"
> потому что без сишного ABI он никому не нуженПлюсы без extern "C" тоже мало кому нужны.
Но это как раз стиму выбросить сишку отовсюду откуда возможно.
И все писать на расте))
Это просто невозможно, у Rust нет собственного ABI, зато например есть у Go.
> Это просто невозможно, у Rust нет собственного ABI, зато например есть у Go.https://doc.rust-lang.org/reference/items/external-blocks.html
The following ABI strings are supported on all platforms:
unsafe extern "Rust" – The default ABI when you write a normal fn foo() in any Rust code.
unsafe extern "C" – This is the same as extern fn foo(); whatever the default your C compiler supports.
unsafe extern "system" – Usually the same as extern "C", except on Win32, in which case it’s "stdcall", or what you should use to link to the Windows API itself
There are also some platform-specific ABI strings:
unsafe extern "cdecl" – The default for x86_32 C code.
unsafe extern "stdcall" – The default for the Win32 API on x86_32.
unsafe extern "win64" – The default for C code on x86_64 Windows.
unsafe extern "sysv64" – The default for C code on non-Windows x86_64.
unsafe extern "aapcs" – The default for ARM.
unsafe extern "fastcall" – The fastcall ABI – corresponds to MSVC’s __fastcall and GCC and clang’s __attribute__((fastcall))
> Это просто невозможно, у Rust нет собственного ABIТы не поверишь, но у Сишочки его тоже нет, ибо оно специфично для платформы. Если не веришь, то попробуй найти его упоминания в сишочном стандарте.
> Ты не поверишь, но у Сишочки его тоже нет, ибо оно специфично для платформы. Если не веришь, то попробуй найти его упоминания в сишочном стандарте.Ты просто бьешь ниже пояса!
Или ты надеялся, что хотя бы половина местных 🤡 хотя бы открывала текст стандарта?
Зря мой друг, очень зря)
... и просто выбросить.
Режим, при котором для компиляции программы нужно будет проходить KYC (шутка).
Си - сила! Лучший язык программирования. И не стоит на месте, а развивается, не ломая совместимость при этом. А все нападки на Си - спланированная и оплаченная кампания по дескридитации с целью вытеснить независимых разработчиков из мира свободного ПО.
Рептилоиды придумали раст, чтобы подсадить на него человечество извести сишников, и больше никогда человечество не смогло вернуться к гнутым истокам как завещали наши великие предки.> спланированная и оплаченная
Зачем дурачкам платить, дурачки за просто так будут в лепешку расшибаться чтобы доказать чтото.
> чтобы подсадить на него человечество извести сишниковДа, подсадная утка, 100%!
> И не стоит на месте, а развивается, не ломая совместимость при этом.Аж жЫр с монитора потек.
> кампания по дескридитации
Никто не дискредитирует сишников так хорошо как сами сишники.
> оплаченная
Не правда! Я абсолютно без-воз-мезд-но, то есть даром (с) и с огромным удовольствием пишу про сишные дырени везде где можно. Ведь многие люди не знают про опасность, которую таит в себе 6ыdloкод не небезопасном йазычке из 70х! А потом они удивляются как их телегу ломают просто прислав "специально оформленное изображение".
Люди просто должны об этом знать, думать об этом, писать своему депутату "а вдруг в этом авто используется опасный код?!" и требовать запрета небезопасных языков.
И по последним изменениям видно, что эта деятельность дает свои плоды.
> Никто не дискредитирует сишников так хорошо как сами сишникиВесь лучший базовый софт, за счёт которого ещё не рушится, не смотря на все старания некоторых, а прочно стоит огромное здание современного IT, написан на Си.
> Весь лучший базовый софтА давай посчитаем, какой софт написан на сишечке, а какой на c++. С чего начнем?
С компиляторов? Оба два оптимизирующих на с++.
С ос? Видна это с++ и даже раст, макось - обжси.
С офисных пакетов? Там нет сишечки.
Может игрульки? На сишке нет ни одного современного движка.Так что написано на си, кроме ядра линя и то, только потому что фин не признает своих ошибок?
> прочно стоит огромное здание современного IT, написан на Си.
"Прочно" стоит на шатком фундаменте дырявейших поделий вроде libxml2)))
> С чего начнем?Да хотя бы Apache и nginx - несущие платформы всего сегодняшнего интернета! И с этим они более чем отлично справляются, и Си никак не мешает, если голова на плечах есть.
> Видна это с++ и даже растАхаха) Ну с этим глюкодромом всё понятно, хороший антипример!)
>> Винда это с++ и даже раст
> Ахаха) Ну с этим глюкодромом всё понятно, хороший антипример!)Про глюкодром это личный опыт)?
Неужели она более падучая чем плазма или более блевотная чем всякие крыски?
Удивительно, что такой классный линукс имеет 5% дестопа!Но примеры великих СИшных программ ты так и не привел)
ps нгикс это та самая программ в которой
opennet.ru/opennews/art.shtml?num=61269"... судя по исправлениям в коде уязвимости вызваны обращением к уже освобождённой памяти (use-after-free), неверным выделением памяти под массив, разыменованием нулевого указателя и отсутствием должной проверки размера помещаемых в буфер данных."
Т.е типичная СИшная дрыстня.
> ps нгикс это та самая программ в которой
> opennet.ru/opennews/art.shtml?num=61269И что? WWW по всему миру из-за этого лёг?)
> Но примеры великих СИшных программ ты так и не привел)А что, Apache и nginx - движков всея интернета тебе мало? Ну тогда git, например - система контроля версий, покорившая весь мир, что скажешь?
> С ос? Видна это с++ и даже раст, макось - обжси.ты путаешь магазины и ОС, смысл с тобой разговаривать
Назрел такой вопрос: проблема в программистах или на С/С++ просто невозможно писать безопасный код? Хочу научиться программировать и разрываюсь между С/С++ и Rust. Если проблема лишь в компетентности - выберу первые языки, но если это архитектурный изъян - второй.
Ни на каком языке невозможно писать безопасный код - это архитектурный изъян человеческого мозга. Можно встроить в язык кучу костылей, которые снизят риск ошибок при работе с памятью, но это никак не поможет от совершения логических ошибок, которые приводят к уязвимостям.
> Можно встроить в язык кучу костылей, которые снизят риск ошибок при работе с памятью, но это никак не поможет от совершения логических ошибок, которые приводят к уязвимостям.Извини, дружок, но более 70% уязвимостей как раз таки от ошибок при работе с памятью, а не от логических.
Важно не количество, а последствия. Много уязвимостей при работе с памятью обнаруживаются - это хорошо, значит программы, написанные на Си, поддаются исследованию на предмет безопасности. А попробуй-ка найди уязвимости, которые наговнокодил какой-нибудь растовщик в состоянии расслабленного мозга...
> Важно не количество, а последствия.heartbleed, dirty COW, тысячи уязвимостей в либах типа glibc, libwebp и прочих с последствиями от denial-of-service до удаленного выполнения кода.
> Много уязвимостей при работе с памятью обнаруживаются - это хорошо, значит программы, написанные на Си, поддаются исследованию на предмет безопасности.
Ага, а потом читаешь новости "в XOrg нашли уязвимость 1988 года"))
Грязная корова жила я ядре с 2007 года до 2016.
Куда пырились все это время тысячи глаз - вопрос открытый.Bashdoor/Shellshock целое семейство CVE - выявили в 2014, были созданы в 1992.
Heartbleed - всего-то 3 года - приятное исключение))
> А попробуй-ка найди уязвимости, которые наговнокодил какой-нибудь растовщик в состоянии расслабленного мозга...
Как говорится "делай хорошо - хорошо будет". Просто не пиши на ущербном недоязыке из прошлого века и не придется разбирать уязвимости.
> последствиями от denial-of-service до удаленного выполнения кодаНу и? Какие последствия-то кроме эфемерных возможностей "удалённого выполнения кода"?
> "в XOrg нашли уязвимость 1988 года"И сильно кому-то повредила эта уязвимость 88-го года?..
Все эти слова про теоретические уязвимости - пустота, за ними ничего реального не стоит, все масштабные сбои и взломы последних лет - чисто криворукость админов, хранивших пароли в файле passwords.txt, чем хакеры и пользовались.
> Просто не пиши на ущербном недоязыке из прошлого векаПросто не пользуйся круглыми колёсами прошлого века - катайся на треугольных - они дадут тебе совершить опасный манёвр на большой скорости и позаботятся о твоей безопасности!
> Ну и? Какие последствия-то кроме эфемерных возможностей "удалённого выполнения кода"?Каких эфемерных?
Вот типичная СИшная либа - libwebp
opennet.ru/opennews/art.shtml?num=59746
"критическая уязвимость вызвана переполнением буфера в обработчике формата изображений WebP. Уязвимость позволяет выполнить свой код при обработке специально оформленных WebP-изображений. Опасность уязвимости усугубляет то, что в сети выявлен рабочий эксплоит, который уже применяется злоумышленниками для совершения атак (0-day). "> Все эти слова про теоретические уязвимости - пустота, за ними ничего реального не стоит, все масштабные сбои и взломы последних лет - чисто криворукость админов, хранивших пароли в файле passwords.txt, чем хакеры и пользовались.
Да что ты несешь! (с)
Не чувак, реально хватит порочу чушню.Bashdoor - через него делали ботнеты,
Dirty COW - через нее ломали и линукс серваки (Ebury) и андроид телефоны.
Даже сайт kernel.org ломанули и бекдор жил два года.
opennet.ru/opennews/art.shtml?num=61186Хватит куракекать про "теоретические уязвимости", просто не позорься.
> Просто не пользуйся круглыми колёсами прошлого века - катайся на треугольных - они дадут тебе совершить опасный манёвр на большой скорости и позаботятся о твоей безопасности!Хе, твоя аналогия просто ущербна /_-
Давай сравним круглое деревянное колесо как на первых авто, с каучуковым покрытием.
И современное бескамерное с радиальным кордом и литым диском.
Ну так во СИшка, это каменное колесо)
> Давай сравним круглое деревянное колесо как на первых авто, с каучуковым покрытием.
> И современное бескамерное с радиальным кордом и литым диском.
> Ну так во СИшка, это каменное колесо)И какое из них до Казани доедет?
Ни на каком языке невозможно писать безопасный код, но сишечка тут вне конкуренции. Напихали в ассемблер высокоуровневых абстракций, запретили goto и назвали языком программирования высокого уровня.
В случае с С/С++ это человеческий фактор, так как компилятор ни о чём не предупреждает.
А в Rust компилятор все спорные ситуации покажет и откажется такой код компилировать.Я, как ленивая жопа, предпочитаю писать на Расте, так как это требует меньше когнитивных напряжений.
То есть, технически возможно писать безопасный код на С/С++? Все верно?
> То есть, технически возможно писать безопасный код на С/С++? Все верно?Технически, можно переделать стиральную машину или холодильник в космический корабль или подводную лодку, все верно.
Стиральную машину или холодильник в подводную лодку нельзя. Толщина металла не позволит выдержать внешнее давление.
> Стиральную машину или холодильник в подводную лодку нельзя. Толщина металла не позволит
> выдержать внешнее давление.Это если у тебя руки кривые!
А если правильно переделывать, то все безопасно будет выдерживать!
Короче, не делай плохо, делай хорошо!
Бензопила это безопасный инструмент?Допустим что да, тогда отбиться ей от нашествия зомби нельзя, а значит она не нужна
Допустим что нет, и маньяк может запилить десяток человек забежав на детский утренник, а значит она не нужна.
Пользуйтесь пилкой для ногтей
От зомби не поможет никак, но можно засадить комуто в глаз..но так их сейчас из пенопласта делают, абсолютно безопасная, но можно ее порезать и устроить так чтобы ктото задохнулся..но задушить можно и руками, черт. абсолютно безопасно только то чего не существует, но идеи убивают похлеще всяких оружий...то есть технически..ну вы поняли
И тем не менее, в бензопиле — даже самой примитивной — есть защита от нелепых случайностей. А уж про то, что в приличном обществе кулаками (и уж тем более бензопилами) нельзя решать свои проблемы так и вовсе напоминают всю жизнь — и родители, и в школе, и на заседании суда. Абсолютная безопасность так-то не нужна. Нужно достаточно безопасности для защиты от распространённых ошибок, будь то в программировании, воспитании детей, валке леса или езде на мотоцикле.
То что возможно сломать будет сломано
> С/С++Нет такого языка. Есть Си, а есть С++ (на котором можно писать как на си, но не надо так!)
Внимательность человека это тоже ресурс и он конечен.
У кого-то больше, у кого-то меньше, но всегда наступает момент когда человек допускает ошибку. Поэтому намного лучше выбирать язык, где тупые и рутинные действия проверяет компилятор, чтобы расходовать свою внимательность на что-то более важное - логику программы.Современный с++ неплох, начиная наверное с с++17. Но наследственные дефекты си в нем остались. Писать нормально на нем можно, но довольно сложно и "дорого".
Можно почитать какой ценой досталась надежность напр. llvm, сколько человекочасов они потратили на тесты, фаззинг, санитайзеры и так далее.
Прямо указал что языки, а не язык.
> Поэтому намного лучше выбирать язык, где тупые и рутинные
> действия проверяет компилятор, чтобы расходовать свою внимательность на что-то более важное
> - логику программы.с каких пор программирование это рутина? вы каждый раз заново пишите, допустим алгоритм сложения двух чисел и боитесь в какой-то момент по невнимательности допустить всякого рода целочисленных переполнений? От такой рутины должен спасть вас язык, компилятор и т.д.? Я вот думаю вы вовсе не программированием занимаетесь, а как сами описали - рутиной.
> с каких пор программирование это рутина?А где там написано что "программирование это рутина"?
Там написано про рутинные действия в рамках программирования. Это огромная разница.
В любой работе есть рутинные элементы, а есть творческие.Даже в художке - подготовка холста, мойка кисточек и тд - это рутина. И кстати именно поэтому многие просто покупают готовых холст в магазе или автомойку для кисточек - они не хотят тратить свое время на ерунду, а хотят творить.
Вот раньше диды в vi писали код, и имя каждой переменной/функции полностью вписывали.
А сейчас эту рутину делает IDE в виде автодополнения.> вы каждый раз заново пишите, допустим алгоритм сложения двух чисел и
> боитесь в какой-то момент по невнимательности допустить всякого рода
> целочисленных переполненийНе боюсь потому что в нормальных языках там нет проблемы.
А в "особенных" нужно задумываться "а что будет если будет переполнение?", "а как именно оно будет реализовано?", а "что если компилятор будет другой? или версия обновится?"
> А сейчас эту рутину делает IDE в виде автодополненияЯ вспомнил об этом 10 лет назад, когда в одной отечественной cms неправильно писал название функции getTreeStucture и не понимал, почему оно её не находит. Оказалось, потому что я писал её без автодополнения и без ошибки как getTreeStructure, а разработчики этой cms один раз написали неправильно а потом только автодополняли. Лучший способ не допустить ошибку - это скрыть ошибку.
А в чем ошибка-то?
Опечатка в имени функции никак не влияет на то, во что эта функция скомпилится.
Оно никак не влияет на работу программы.
> А где там написано что "программирование это рутина"?
> Там написано про рутинные действия в рамках программирования. Это огромная разница.#include <stdio.h> рутина?
> Даже в художке - подготовка холста, мойка кисточек и тд - это рутина. И кстати именно поэтому многие просто покупают готовых холст в магазе или автомойку для кисточек - они не хотят тратить свое время на ерунду, а хотят творить.
#include <stdio.h> - ерунда? зачем тратить на это время, особенно всякие макросы в языке. Я вообще не воспринимаю языки с макросами в том числе и Си. Рутина за которую вы говорите и есть достижение идеала в собственных действиях, оттачивание мастерства, а как без повторения оттачивать их до идеала? Как нарисовать шедевр на холсте низкого качества? Чтобы создавать шедевры, там все должно быть идеальным, каждый шаг который вы считаете рутиной.
> А сейчас эту рутину делает IDE в виде автодополнения.
А зачем мне это нужно будет во времена когда какой-то ЫЫ за меня все это будет генерировать?
> А в "особенных" нужно задумываться "а что будет если будет переполнение?", "а как именно оно будет реализовано?", а "что если компилятор будет другой? или версия обновится?"
Если вам не надо об этом задумываться, то зачем вам вообще думать о программе, пусть ЫЫ пишет код. Ровно это и нужно, чтобы человек тупо перестал думать. Ок, ваше право.
Отлично.> чтобы расходовать свою внимательность на что-то более важное - логику программы.
Ок, допустим внимательности Х - const, и за 3 дня человек допускает Y ошибок, тогда логичнее их допустить в рутинных вещах, изза которых программа либо не собирется, либо не запустится, что укажет на ошибку, чем через 10 лет обнаружить, что логика кривая.
> тогда логичнее их допустить в рутинных вещах, из-за которых
> программа либо не собирется, либо не запустится,Именно. Вот только это про раст, а не про си.
Ты накосячил - компилятор просто не скомпилит это.
А сишку он скомпилит, запустит, а потом через Т лет окажется что 28 backspace позволяют обойти ввод пароля.> чем через 10 лет обнаружить, что логика кривая.
Да, именно так! Поэтому лучше тратить внимательность на логику, а не на ерунду.
> лучше тратить внимательность на логику, а не на ерунду.Я без предъяв, но вы не рассматриваете вариант, что тратя внимательность на ерунду я эту самую внимательность развиваю?
> тратя внимательность на ерунду я эту самую внимательность развиваю?Возможно. Но ты ее точно также развиваешь, тратя не на ерунду.
И этой неерунды ты сможешь сделать намного больше до первой ошибки.
Плюс там есть гарантии, что за тебя проверят и сообщат "если что".
> Назрел такой вопрос: проблема в программистах или на С/С++ просто невозможно писать безопасный код?На такой вопрос тебе никто не сможет ответь на 100%.
Всегда найдется умник с "зачем вы пишете с багами? пишите без багов!".
Но факт того что с С/С++ проблемы перманентные и десятки лет заставляет задуматься)> Хочу научиться программировать и разрываюсь между С/С++ и Rust.
Если у тебя нет образования, я бы начал с алгоритмов и структур данных.
Потому что если у тебя будет фундамент - то в общем-то не так сложно переходить с одного языка на другой.Плюсы еще может имеют смысл - на них пишется много геймдева, пользовательского и научного софта.
СИшка уже безбожно устарела, только легаси и проектры от неосиляторов.Там нет кучи удобных вещей типа Result<value, error> (в С++ появилось в 23 стандарте - expected).
Приходится пробрасывать инты и потом "если -1 то ошибка". А если -2 - то она возможно и не обработается)
Не выглядит ли это просто убого?
Да и приводит к багам, как например тут
opennet.ru/openforum/vsluhforumID3/137136.html#82> Если проблема лишь в компетентности - выберу первые языки, но если это архитектурный изъян - второй.
Проблема в масштабе.
Следить за памятью в проекте из 10к строк легко. А если их будет 100к? Или миллион?
Приходится обмазываться санитайзерами, фаззингом.Так что лучше выбирай СИшку.
У меня, раст разработчика, будет меньше конкурентов ;)
> Но факт того что с С/С++ проблемы перманентные и десятки лет заставляет задуматься)У любого языка, который много лет используется для написания тонн кода, вскроются "перманентные проблемы на десятки лет") "Ошибок нет только у того, кто ничего не делает".
> У любого языка, который много лет используется для написания тонн кода, вскроются "перманентные проблемы на десятки лет")И какие проблемы, с таким импактом CVE/RCE есть у джавы или шишарпа?
Или может у АДА есть проблемы уровня "28 раз нажал бекспейс - пропустил введение пароля"?Ненадо оправдывать бракованные недоязычки.
> "Ошибок нет только у того, кто ничего не делает".
А что делает тот, кто совершает одни и те же ошибки из года в год?
Знаешь, что такое безумие? (с)
> И какие проблемы, с таким импактом CVE/RCE есть у джавы или шишарпа?Всё есть, логические ошибки есть везде.
> А что делает тот, кто совершает одни и те же ошибки из года в год?В том, что ошибки обнаруживаются, нет ничего плохого - значит, тесты работают! Плохо, когда ошибок "как-будто нет" (их просто замаскировал "умный" компилятор), а потом эти скрытые логически ошибки, не обнаруживаемые тестами, приводят к катастрофическим последствиям...
> А что делает тот, кто совершает одни и те же ошибки из года в год?Имеете ввиду тот, кто из года в год придумывает всё новые "безопасные" языки, которые уж на этот-то раз точно избавят программиста от ошибок?
Ну, раз вы спросили, лично я думаю, что они это не для каких-то целей делают а просто потому что им захотелось создать новый язык с какой-нибудь фишкой. У кого-то это байткод и своя виртуальная машина размером с реальную, у кого-то отступы пробелами, у кого-то интерпретатор угадывающий нужна ли здесь точка с запятой или нет, у кого-то прикольный синтаксис, у кого-то компилируемость и при этом бинарник HelloWorld в несколько мегабайт.
> А что делает тот, кто совершает одни и те же ошибки из года в год?
> Знаешь, что такое безумие? (с)Криворукость сишников никто не отменял, но из этого не может следовать, что на си нельзя писать корректные "прямые" программы. По безумцам в обществе нельзя судить о пандемии, она должна носить тотальный характер.
Много работал с C/C++ в начале-середине 2000-х, но в некоммерческом применении. Сейчас эпизодически сталкиваюсь с ним. Про rust знаю только из новостей и (многочисленных) комментариев к ним. Всё ниже перечисленное (особенно касающееся rust) - исключительно мое субьективное мнение.На C/C++ можно писать безопасный код. Но для этого нужно:
- огромнейшая квалификация (например, необходимо знать ВСЕ undefined behavior), по ощущению, из 1000 C-программистов такая есть в лучшем случае у двоих,
- просто нереально огромное внимание к деталям: там, где вы описываете алгоритм и думаете над его реализацией, вам попутно необходимо думать и о куче мелочей типа "можно ли для сложения двух целых переменных просто написать a+b, или их сумма может превысить размерность переменной, и это необходимо сначала проверить и каким-то образом сгенерировать ошибку"; кроме совсем критичных областей, работодатель не даст столько времени на программирование.Как результат, на практике практически никто никаких проверок не делает.
Исторически С был высокоуровневым ассемблером и по сути использовался для более читабельной записи ассемблерного кода. Многие пишущие на C примерно понимали, как будет выглядеть ассемблерный код. Именно поэтому там нет строковых операторов, а только функции типа str* - процессор не умеет работать со строками. Именно поэтому там появилось многократное присваивание типа "a = b = c = d;" - один раз взять одно значение и записать в несколько переменных эффективнее, чем читать это значение из памяти каждый раз. Именно поэтому там куча undefined behavior: программист писал "a + b" и понимал, что это будет "add a, b", а переполнения будут обрабатываться в зависимости от процессора: на интелах просто отсечение старших битов и установка регистра флагов, на каких-нибудь моторолах - исключение и падение программы (написал просто для понимания, как именно переполнение обрабатывалось моторолами не знаю).
Это одна из причин, когда лет 15 назад (или больше?) была история, как Линус Торвальдс реализовал на голом C какую-то сумму типа sha256 и его код работал быстрее, чем код из openssl с поддержкой всяких sse и avx, - Линус просто понимал, какой конкретно бинарный код будет скомпилирован из его исходника.
Но последнее время (ну, лет 15-20) идёт сильный сдвиг C/C++ (особенно C++) в нишу "прикладных" языков, которые не зависят от железа. С добавлением соответствующих характеристик. Если в 80-е программист писал "add a, b" и точно знал, как результат поведёт себя на его конкретной машине, то сейчас авторы gcc явно используют undefined behavior для микрооптимизаций (на что тот же Линус Торвальдс много ругался несколько лет назад), и ваше a+b может уронить программу не потому что ваш процессор так работает, а потому что gcc знает что КАКОЙ-ТО процессор может уронить программу и поэтому даже для вашего процессора генерирует немного более оптимизированный код, но который может падать если сумма не входит в размерную сетку.
Rust же изначально был "оторван" от ассемблера и просто предлагает низкоуровневые абстракции, но без привязок к конкретному процессору.
Кроме того:
- rust защищает ТОЛЬКО от ошибок работы с памятью; всякие sql-инъекции, логические ошибки и всякое другое он не способен проверить; есть мнение, что rust, защищая от ошибок памяти, расслабляет программиста и отучает его думать и о других ошибках.
- Что касается синтаксиса, то C однозначно проще, чем rust, но вот последние версии C++ успешно борются с rust за звание наиболее ущербного.
- C/C++ имеют стабильные "релизы" языка; раст же постоянно меняется; вполне допускаю, что при нынешних скоростях развития лет через 10 раст будет объявлен устаревшим и на смену ему придёт что-то новое, а C/C++ для "небезопасных" программ будет ещё актуален; хотите постоянно бежать за всё обновляющимся растом или предпочтёте изучить что-то, что ещё долго будет актуальным? С другой стороны, сейчас раст слишком сильно форсируется крупными компаниями, этакий systemd. Есть шанс, что через 10 лет новые проекты на C/C++ начинаться вообще не будут.По ощущениям, раст защищает программиста от выстрела в жизненно важные органы, причём даже если пациент смертельно болен и для него это стало бы спасением. Но от выстрела в ногу он не защитит.
> Много работал с C/C++ в начале-середине 2000-х, но в некоммерческом применении.Ну... не хочу обидеть, но некоммерческом применение это немного
> На C/C++ можно писать безопасный код.
Но такой код получается только при неограниченном бюджете, типа "запилить марсоход".
> Как результат, на практике практически никто никаких проверок не делает.
И это печально.
> Исторически С был высокоуровневым ассемблером и по сути использовался для более читабельной записи ассемблерного кода. Многие пишущие на C примерно понимали, как будет
> выглядеть ассемблерный код."Примерно" - это правильное определение)
> Именно поэтому там куча undefined behavior: программист писал "a + b" и понимал, что это будет "add a, b", а переполнения будут обрабатываться в зависимости от процессора
Неа. Если бы оно было так, то это было бы Implementation behavior.
А undefined - это вообще "не знаем как оно себя поведет".> Но последнее время (ну, лет 15-20) идёт сильный сдвиг C/C++ (особенно C++) в нишу "прикладных" языков, которые не зависят от железа.
Это началось еще давно, с появления кучи разного железа.
Даже процессоры одного производителя могут иметь разные характеристики.> Если в 80-е программист писал "add a, b" и точно знал, как результат поведёт себя на его конкретной машине,
А как же портируемость)? Это же оплот защитников СИ - мол можно скомпилять под кучу платформ.
О том что оно не факт что будет работать корректно - предпочитают умалчивать).> Rust же изначально был "оторван" от ассемблера и просто предлагает низкоуровневые абстракции, но без привязок к конкретному процессору.
Ага. Потому что сейчас компилятор гораздо лучше оптимизирует код.
Причем "сейчас" это лет 20) Можно вспомнить историю с иксами и раскруткой циклов.> - rust защищает ТОЛЬКО от ошибок работы с памятью; всякие sql-инъекции, логические ошибки и всякое другое он не способен проверить;
Во-1х, ошибки памяти это топ ошибок, как по кол-ву, так и по последствиям.
cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
Memory Corruption - 2341
Overflow - 328Во-2х, логические ошибки можно предотвращать.
Например при помощи системы типов. И паттерн матчинага. И enum type который отличается при сравнении, а не "сравнил крокодилов с апельсинами, фигли там все равно int под капотом".
Ну чтобы не было такого "функция при ошибке возвращает -1, а она вернула -2, все твои данные ушли хакерам".> есть мнение, что rust, защищая от ошибок памяти, расслабляет программиста и отучает его думать и о других ошибках.
Звучит как разговоры старых водил, что с автоматом все разучатся водить)
Или "вы с вашими калькуляторами вообще считать разучитесь!"
> - C/C++ имеют стабильные "релизы" языка; раст же постоянно меняется;Не совсем правда.
У раста есть edition.
doc.rust-lang.org/edition-guide/editions/Которые выходят каждые 3 года и содержат ломающие изменения. Т.е прямой аналог версии С или С++.
В проекте можно зафиксировать версию... и все будет работать даже с последним компилятором.
Например андроид зафиксировал rust 2018.> а C/C++ для "небезопасных" программ будет ещё актуален; хотите постоянно бежать за всё обновляющимся растом или предпочтёте изучить что-то, что ещё долго будет актуальным?
И опять полу правда.
В С++ АБИ частично ломается примерно каждые 3 версии.
Посмотрите статьи про последнии редакции:
Член WG21 пишет что слом АБИ позволяет ускорит некоторые функции на 200-300%.
open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdfНо к сожалению его не послушали.
cor3ntin.github.io/posts/abi/> С другой стороны, сейчас раст слишком сильно форсируется крупными компаниями, этакий systemd.
Форсируется - это как? Они нанимают для своих проектов раст программистов?
Ну так это их право. Возможно они просто устали от бесконечных ошибок.> Есть шанс, что через 10 лет новые проекты на C/C++ начинаться вообще не будут.
Я тоже на это надеюсь.
Было бы классно еще на уровне государства сделать требование "проекты за гос деньги только на безопасных языках".> По ощущениям, раст защищает программиста от выстрела в жизненно важные органы, причём даже если пациент смертельно болен и для него это стало бы спасением.
А можно такой пример?
> Но от выстрела в ногу он не защитит.
Серьезное заявление, требующее доказательств.
В качестве опровержения, я приведу пример андроида
security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
> Ну... не хочу обидеть, но некоммерческом применение это немногоНикаких обид :) Для того и написал, чтобы читающий мой ответ, понимал, какого уровня человек ему отвечает. В коммерческой разработке условия совсем другие, все эти сроки, гарантии, копания в чужом коде и т.д.
> А как же портируемость)?
В то время в этом и заключалась портируемость. a+b гарантированно сложит два числа на любом процессоре с минимумом накладных расходов, а вот мелочи уже будут на совести процессора. То же и с разрядностью типов типа int, который просто "не менее 16 бит", а сколько конкретно - непонятно.
> Звучит как разговоры старых водил, что с автоматом все разучатся водить)
Ага. Но по сути так и получается. Случись чего - многие полезут под капот? Меньшая самостоятельность, большая зависимость от других людей. А тем только этого и надо - опа и вот уже запчасти за 300% стоимости.
> В С++ АБИ частично ломается примерно каждые 3 версии.
А вот этого не знал, спасибо за информацию. Последний раз слышал о чём-то типа добавления поля count в списки, что ломало совместимость из-за изменения размеров объектов. Но я думал, что это разовое событие исключительной редкости.
> Форсируется - это как?
Про "нанимают раст-программистов" не скажу, но наверное да. Но суть в том, что очень много чего сейчас пишется на расте. Периодически в новостях вылезает из самых неожиданных мест. Имхо пока это хайп, как с ии или блокчейном. Но во что оно выльется, предсказать сложно. Сдуется, или ограничится какой-то нишей, или реально заменит C/C++.
> А можно такой пример?
Нет, я же не знаю раст :) Но в разных других местах, когда вводится что-то "для безопасности", оно часто бьёт и по нормальному использованию. Тот же ркн, блокирующий опасные сайты, блокирует и кучу нормальных сайтов... причём, больше нормальных чем опасных.
> > Но от выстрела в ногу он не защитит.
> Серьезное заявление, требующее доказательств.Я имел ввиду, что от каких-то типов ошибок оно не защитит, и программист всё равно должен понимать, что он делает.
> Никаких обид :)🤝
У меня просто 15 лет комерческой разработки... и там все бывает очень жестко.>> А как же портируемость)?
> В то время в этом и заключалась портируемость. a+b гарантированно сложит два числа на любом процессоре с минимумом накладных расходов, а вот мелочи уже будут на совести процессора.Типа "я сказал ему сложить 2 числа, а вот какой результат, это не я несу ответственность".
Я бы называл это "портируемость" в кавычках.> Ага. Но по сути так и получается. Случись чего - многие полезут под капот?
А зачем? Может я хочу купить надежное авто, к которому я не хочу лазить под капот?
Например - раньше надо было настраивать зазоры клапанов каждые 5тыщ пробега.
Занятие малоприятное, но тк ничего кроме жигулей не было - деваться некуда.А потом появились гидрокомпенсаторы.
"А что так можно было?!" (с)> Меньшая самостоятельность, большая зависимость от других людей.
Цивилизация началась с разделения труда.
Я не пеку хлеб, не ремонтирую авто. Лечить зубы я тоже пойду к профи.
Раньше можно было спаять из ворованных деталей Радио86, а сейчас даже ноут починить без bga пайки не выйдет.
Но мне что-то не хочется возвращаться в те времена)))> А тем только этого и надо - опа и вот уже запчасти за 300% стоимости.
Наверное что-то случилось)
>> В С++ АБИ частично ломается примерно каждые 3 версии.
> Но я думал, что это разовое событие исключительной редкости.К счастью нет. Тк язык должен развиваться.
Но никто не запрещает писать на условном rust 2018 или с89 долгие годы.
Ядро перешло с 89 на с11 только в 2022, ЕМНИП.> Про "нанимают раст-программистов" не скажу, но наверное да. Но суть в том, что очень много чего сейчас пишется на расте. Периодически в новостях вылезает из самых неожиданных мест. Имхо пока это хайп, как с ии или блокчейном.
Ну, по первому пункту - это бизнес, если они видят, что разработка на расте может быть выгоднее - они его пробуют.
Хайпа я тут не особо вижу, рекламы по ТВ и интернете нету (как java - youtube.com/watch?v=SRLU1bJSLVg)
То что гугл в своем блоге что-то пишет, ну мало кто его читает.> Сдуется, или ограничится какой-то нишей, или реально заменит C/C++.
Уже заменяет.
В андроиде 13 было 1.5 млн. строк код. В 16 версии еще больше.
Крупный бизнес cloudflare, microsoft, AWS пишет открытый код на нем.
Вольво внедряет в машины, китайцы в смарт часы и спутники.> Нет, я же не знаю раст :)
> Но в разных других местах, когда вводится что-то "для безопасности", оно часто бьёт и по нормальному использованию.Тогда, если вы не против, я поясню.
Одна из основных фич раста - проверка на этапе компиляции. Это имеет некоторые трейдоффы: компиляция может быть дольше, дебажный билд может быть существенно больше.
Но то что скомпилировалось 1 раз, у тысяч пользователей будет работать быстро.
По бенчмаркам выходит отставание на 1-2% в некоторых алгоритмах и одинаковая производительность в других.> Тот же ркн, блокирующий опасные сайты, блокирует и кучу нормальных сайтов... причём, больше нормальных чем опасных.
Я бы не критиковал РКН на этом сайте, если вы не сидите через ТОР.
> Я имел ввиду, что от каких-то типов ошибок оно не защитит, и программист всё равно должен понимать, что он делает.
Естественно. Он должен понимать логику и алгоритмы.
Но если мы избавимся от целого пласта проблем с памятью, то можем уделять внимание логике.
Я выше привел ссылку на CVE ядра. Memory проблемы это топ с огромным отрывом.
Программист на Rust без знаний С и С++ никому не нужен.
язык C/C++ для программистов, раст - для веб-синьоровплюсы учат по книгам, раст по туториалам. делай выводы
> плюсы учат по книгами начинать нужно с таких книг, как эта, чтоб потом не было жаль потраченного времени
https://github.com/Nekrolm/ubbook
я не понимаю, вас прямо на курсах пугают UB? вы же, бедные, так заиками станете, ни разу UB и не увидев
>Хочу научиться программироватьВы для удовольствия хотите научиться программировать или чтобы зарабатывать этим?
Во-первых, ни C, ни C++, ни Rust не подходят для начального обучения программированию.
Во-вторых, если вы хотите стать профессиональным программистом, то , извините за вопрос, а сколько вам лет? Если вам уже больше 13 лет и вы до сих пор не умеете программировать - извините, уже поздно начинать. Будущие профессиональные программисты к 15-ти годам уже пишут свои простенькие игры и вирусы. Соревноваться с ними на рынке труда вы не сможете.
Если же вы ещё молоды и у вас всё впереди - совет: изучать надо все языки, и C, и C++, и Rust, и Python и ещё много-много других языков. Профессиональные программисты знакомы с не меньше чем 20-ю языками.
Как получится... мне 40 лет, но не думаю что это настолько серьезно препятствие.
Это надеюсь шутка? У нас лид, ему за 40, долго работал ментом, а потом стал программистом. Другой чел на ржд, путейщиком работал, получил 12 грейд в сбере, ща в альфу ушел на 500к в месяц. Я нагрузочник, 400к получаю и я до 34 лет на ржд работал. Вирусы в 13лет? а ты много знаешь, кто в 13 на ассебмлере полиморфы и стелс вирусы пишет? Особенно в 2025году.
Читайте внимательно: в 15 лет, а не в 13. И не полиморфы и стелсы, а простые. Все дети начинают программирование с игр и вирусов, вы бы это знали если бы в детстве ходили в кружок программирования.
2025 год - ничем не особенный, потому что за последние 2 тысячи лет мозг у людей не изменился.
А шутка - это то, что вы написали про путейщика и мента.
Уже приступил к изучению и С мне не показался сложным языком.
Сложен, если не знаешь алгоритмы. Лёгок, если знаешь алгоритмы. Таков чистый Си.
Из литературы, выбрал пал на учебник по С/С++ от братьев Дейтел и "Алгоритмы и структуры данных" от Вирта. Что скажете?
К сожалению, невозможно научиться программировать по двум книгам, даже по 10 книгам, даже по 20 книгам, пусть даже они и лучшие.
Программирование - это не наука, это какой-нибудь раздел математики можно изучить, прочитав несколько книг по нему.
Кроме учебников нужны справочники, задачники (с ответами) и наставник (тьютор), который будет подсказывать как более оптимально решить задачу. И инженерные способности.
Согласитесь, книги - это бесценный источник информации и чужого опыта. Представьте себе изучение математики или физики... без книг. Да, книги по программированию не сделают из меня программиста - не в этом их назначение. Но без книг - я им точно не стану!
Я и не спорю, наоборот, желаю успехов. Языки программирования - это, на самом деле, не сложно. А сложна предметная область.
Боже, сколько понтов… И способности нужны, и задачники, и наставник, и чёрт в ступе. Программирование — дисциплина в первувю очередь практическая, и во вторую прагматическая и только потом уже Вирт, деревья, алгоритммы и всё остальное. Чтобы научиться программировать надо программировать. Тогда появятся и вопросы, на которые можно найти ответ в то числе в книгах, и друзья по интересам, и наставники на первом же месте работы. А не появятся — тоже не беда, главное чтобы проблема решалась. Даже костыльный код лучше, чем комментарии на опеннете. Код хотя бы исправить можно.
Это довольно порочный путь - авось как-нибудь сложится. Исправлять плохие привычки - всегда мучительно больно.
>С/С++Такого языка не существут. Это две разные языки.
>разрываюсь между С/С++ и Rust.
Итого ты стоишь перед выбором трёх разных языков.
А где утверждалось что С/С++ - это один язык? Разумеется изучая С попутно будет изучаться и С++. Да и явно указывалось что речь идет о языках, а не языке.
Если ты пишешь вантузную абревиатуру "C/C++", то ты намекаешь о том, что считаешь что это один язык. В среде линуксоидов не принято писать - С/C++.>Разумеется изучая С попутно будет изучаться и С++
А может изучая Си тебе попутно изучить ещё и Java? Это был сарказм. C++ не является потомком или продолжением языка Си. Си плюс-плюсник плохой сишник. Википедисты выдают желаемое за действительное.
У тебя только три пути: либо изучаешь Си - попутно изучая алгоритмы и структуры данных. Либо изучаешь C++, знаниея алгоритмов тебе не понядобятся, будешь изучать сам язык. Либо изучаешь сразу Rust.
Никаких намеков. Полагаю, вполне себе справлюсь и с С и с С++. Они довольно похожи... скорее всего, будут свои тонкости и подводные камни, но это лучше чем учить непохожие на них языки.
Стек похожих языков: C -> C++ -> Java.
Rust ближе к Ada, то есть стек другой: Pascal -> Ada -> Rust.
пиши на Си, если хочешь на Си. Архитектурного изъяна там нет, просто он минималистичный и работать с памятью нужно внимательно, за тобой
Начну с С, а закончу С++. Главное что все упирается в компетентность программиста.
> для усиления защиты по аналогии с добавленным в GCC 14 флагом "-fhardened"И как обычно gcc сделан для людей, а clang - для корпоративных винтиков. И вот тут это все на отличненько вылезает.
Что вам лениво чтоли заучить заклинания вида "-D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -ftrivial-auto-var-init=zero -fPIE -pie -Wl,-z,relro,-z,now -fstack-protector-strong -fstack-clash-protection -fcf-protection=full" ? :)
А вдруг ошибешься в паре слов и Армия Тьмы вырвется на свободу ?
Похоже на страшное заклятие!
Линус бы руки поотбивал
все быстренько включили опцию и побежали покупать новый цпу
По-нормальному, опции усиленной защиты ставятся только в отладочной версии, чтобы легче отловить ошибки при тестировании.
А потом — вроде как работает? херак-херак и в продакшн!
> По-нормальному, опции усиленной защиты ставятся только в отладочной версии, чтобы легче
> отловить ошибки при тестировании.Правильно - намного веселее если разнесут в щепки прод. Аэрофлот проверял, очень круто ощущается.
Сейчас нет профи программистов которые знают раст, но не знают С/С++. Си все равно надо изучить в какой-то степени прежде раста
"Сначала научись ездить на жигулях"