Здравствуйте, Shmj, Вы писали:
S>Хорошая ли идея связаться с Rust?
Лично я считаю, что для работодателя спонсирующего проект лучший выбор это Си или C++. Тоже самое для независимого программиста. Если по каким-то причинам работодатель выбирает иную технологию и готов за неё платить, то знающему программисту нет повода отказываться от этой работы.
В конце концов ущерб понесёт работодатель, а не наёмный программист. На иных технологиях работодатель столкнётся с отсутствием кроссплатформенности, готовых библиотек алгоритмов, в некоторых случаях зависимостью от поставщика и многим другим.
Но это знаешь многим плевать. Например, говорили же людям не используйте облачные сервера, просто тупо купите своё "железо". Нет, люди покупали облака, на них завязывали софт. Про сертификаты я тоже говорил, что это разводилово на деньги, а не защита, а мне говорили нет, ты не прав. А потом в России после известных событий всё, что я говорил на эту тему сбылось.
Я написал для людей статью Прикладные антисанкционные языки программирования. Кто-то согласился, кто-то надо мной посмеялся, кого-то бомбануло. Но я считаю эти разговоры из разряда подписок на сервера, покупку иностранных сертификатов.
Я ведь не то, что какой-то предусмотрительный, или там начитался Ричарда Столлмана. Просто два десятилетия назад под воздействием маркетологов я тоже лоханулся в выборе и поделился своим видением. Надо было оставаться с двухтысячных на C++, а учиться алгоритмам на Си, а не болтаться как говно в проруби.
Даже маркетолог тебе скажет, посмотри, программисты же дебилы допускают утечки памяти. А вот возьми чудо язык и даже обезьяна напишет "Войну и мир". Но откуда берутся эти недоучки обезьяны. А всё потому что куча языков и до программирования даже порой дело не доходит.
Каждый кричит используй меня, но почему-то приложения которые я использую в основном написаны на Си или C++. Если говорить о теориях заговора, то я вообще считаю, что корпораты специально создают свои языки программирования и продвигают их, чтобы помешать развиваться всем остальным разработчикам.
Да, со мной уже спорили и по этому поводу. Типа ко ко ко, ты не прав, корпорации добра продвигают свои языки программирования ради всеобщего счастья и блага на Земле, а не для того, чтобы тебя контролировать и уничтожить как возможного конкурента. Так вот и живём.
Можно даже специально толкнуть людей на ложный путь. Сказать да, Rust это круто, я на нём сделал кучу проектов, успешный успех. А потом в тайне поржать над новичками, которые в это поверят. По факту не только корпоратам выгодно устранять конкурентов, но так же и работодателям и наёмным программистам.
Так почему же мы говорим своё настоящее мнение, а не строим подлянки для своих коллег. Ещё некоторые и спорят, типа в интернете кто-то не прав, не могу спать, буду переписываться всю ночь чтобы победить в споре. Но никакого спора нет, наступила эра толерастии, хочешь использовать Rust, используй.
Здравствуйте, velkin, Вы писали:
V>В конце концов ущерб понесёт работодатель, а не наёмный программист. На иных технологиях работодатель столкнётся с отсутствием кроссплатформенности, готовых библиотек алгоритмов, в некоторых случаях зависимостью от поставщика и многим другим.
Ущерб понесет пользователь когда из-за очередной уязвимости словит вирус-шифровальщик.
Кроссплатформенность и библиотеки это тоже не сильные стороны C и C++
КБ>Ущерб понесет пользователь когда из-за очередной уязвимости словит вирус-шифровальщик. КБ>Кроссплатформенность и библиотеки это тоже не сильные стороны C и C++
Как много веселых ребят, и все делают велосипед...
Здравствуйте, PM, Вы писали:
PM>Дарю лайфхак — grep "instantiated from here" или просто "here" в выводе от gcc дает имя файл и номер строки.
Вот конкретный пример: https://godbolt.org/z/8bKfe8nxr
где в этом бесполезном эссе от govno compiler collection упоминается строка номер 6, в которой я пытаюсь скопировать объект, для которого копирование невозможно?
А в реальной консоли это эссе в разы длиннее, потому что эти мега-длинные строки переносятся на десять.
Здравствуйте, Carc, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
C>А причем тут вирус-шифровальщик и языки программрования? Какая между ними связь?
Код на си — ошибки работы с памятью — уязвимости — ransomware.
А на нормальном языке этот класс ошибок и уязвимостей полностью отсутсвует.
Здравствуйте, The Passenger, Вы писали:
TP>Здравствуйте, Константин Б., Вы писали:
КБ>>А на нормальном языке этот класс ошибок и уязвимостей полностью отсутсвует.
TP> и даже в виртуальных машинах, которые, между дрочим, пишутся на с и с++?
Да. К сожалению если программу на нормальном языке запускать на платформе написанной на сишечке — то уровень безопасности будет как у сишечки.
Это как строить небоскребы на заминированном болоте вместо фундамента. Но это не повод опускать руки и не исправлять ситуацию к лучшему.
В чястности не надо начинать новые проекты на сишечке, чтобы количество уязвимостей хотя бы не росло.
Здравствуйте, Разраб, Вы писали:
Р>Здравствуйте, CreatorCray, Вы писали:
CC>>Здравствуйте, Разраб, Вы писали:
Р>>>не хуже на мой взгляд чем это CC>>Тут какой то псих пишет LINQ-style кашу. Р>ну как псих. The Reactive Extensions for Native (RxCpp) is a library for composing asynchronous and event-based programs using observable sequences and LINQ-style query operators in both C and C++. Р>, те что в десятке мэйнстримных языков реализованы. Р>Я к тому, что не язык определяет человека, а наоборот. Р>Вот для меня кол-во концепций ++ слишком велико. Р>В расте хотя бы инструменты единые, понятные сообщения компилятора. Р>а ++ я даже не понял какие нужны чтобы модули заюзать под линуксом. Р>а по синтаксису они могут соревноваться.
Так-то в ОП было перечисление ограничений типов, а сама статья писала нытьё про то, как это надо копипастить от impl до impl.
А твой пример — это лютая функциональщина, на js похожая. Это реализовали почти все языки, и, как по мне, везде выглядит как говно (но мнения, конечно, бывают разные).
Это я к тому, что более уместно было бы привести в пример какой-нибудь шаблонный угар из буста, например.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, velkin, Вы писали:
V>>В конце концов ущерб понесёт работодатель, а не наёмный программист. На иных технологиях работодатель столкнётся с отсутствием кроссплатформенности, готовых библиотек алгоритмов, в некоторых случаях зависимостью от поставщика и многим другим.
КБ>Ущерб понесет пользователь когда из-за очередной уязвимости словит вирус-шифровальщик.
А причем тут вирус-шифровальщик и языки программрования? Какая между ними связь?
Здравствуйте, CreatorCray, Вы писали:
S>>Нет, ретроградство и лудизм -- это ассоциировать функциональщину в C++ с забиванием гвоздей перфоратором. CC>Что одно что другое — использование мощного инструмента не по назначению.
К непогрешимости суждений добавляется еще и раздутое самомнение. Полагаю, в вашем присутствии, все ЧСВ-мометры в радиусе 10 метров выходят из строя.
S>>Мне вот удивительно, как человек с такой верой в непогрешимость собственных суждений умудряется еще и узнавать что-то новое. Хотя... CC>Рад тебе сообщить что то новое, но ты лучше отойди от зеркала что ли...
Мне уже столько раз сообщали, что я не умею писать код, ничего не понимаю в разработке, застрял в 1990-х и вообще идиот, что вы точно к этому списку ничего не добавите.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Константин Б., Вы писали:
КБ>> В чястности не надо начинать новые проекты на сишечке, чтобы количество уязвимостей хотя бы не росло.
R>Штука в том, что не начни авторы "правильных языков" проект на сишечке, небыло бы никаких "правильных языков".
Ну а авторы сишечки писали компилятор на чемто еще более древнем, скорее всего ассемблере. И что?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, kov_serg, Вы писали:
_>То есть программист должен не тривиально ублажать язык, вместо решения простой прикладной задачи. Очень показательно.
Это же библиотечный код.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Вот пока в говно не влезешь — оно может выглядеть конфеткой. Ведь все так хвалят. Но как вам это: S>Какой-то душок уже чувствуется.
Библиотечный код же вроде. Какая разница что там автор крейта наговнокодил, если снаружи это удобно используется (из комментария к коду):
Здравствуйте, vsb, Вы писали:
vsb>Ну мне нравится. Я ничего в Rust не понимаю и я даже способен понять общий смысл того, что тут написано. По-моему это не душок, это успех.
Там интересная книга — итог обучения — как бы этот пример. Но можно пойти от обратного — смотрите пример и спрашивайте GPT все, что вам не понятно. Поймете этот пример — уже будет понятно 95% всего кода на Rust.
Мое недовольство было — по количеству бойлерплейт кода.
Здравствуйте, CreatorCray, Вы писали:
CC>>>Тут какой то псих пишет LINQ-style кашу. Р>>ну как псих. CC>На С++ писать функциональщину — это mental disorder
Здравствуйте, vsb, Вы писали:
_>>o_O вычисление среднего не тривиальная задача?
vsb>В типизированном языке, для произвольных типов и с адекватными сообщениями об ошибках при неправильном использовании — я думаю, что не тривиальная.
То есть программист должен не тривиально ублажать язык, вместо решения простой прикладной задачи. Очень показательно.
Здравствуйте, T4r4sB, Вы писали:
S>>Есть принципиальная разница: в Rust-е все эти ограничения формально необходимы. В C++ -- нет,
TB>И это минус С++.
А черное -- это белое, ага.
TB>>> потому что нечитаемых ошибок компиляции от govno compiler collection я насмотрелся.
S>>Вас пожалеть?
TB>Нет, только не надо врать, как легко и классно ты за минуту понимаешь, почему на шаблонном коде govno compiler collection высирает тупое бесполезное эссе на 1000 строк какого-то бреда, в котором нет ни единого упоминания строчки, где действительно произошла ошибка.
Так уж получается, что в последние лет пять в случае с GCC гораздо сложнее разбираться в некоторых других ошибках, а не в том, что связано с шаблонами. Например, синтаксическая ошибка в списке инициализаторов нешаблонного класса может поставить в тупик больше, чем пять экранов описания невозможности инстанциировать шаблон.
Я это к тому, что в C++, исторически, всратая система информирования об ошибках и это не имеет прямое отношения к шаблонам.
Здравствуйте, CreatorCray, Вы писали:
CC>>>На С++ писать функциональщину — это mental disorder S>>Каким-то ретроградством и лудизмом пахнуло.
CC>Ну т.е. забивать гвозди отключенным от питания промышленным перфоратором это "ретроградство и лудизм"?
Нет, ретроградство и лудизм -- это ассоциировать функциональщину в C++ с забиванием гвоздей перфоратором.
CC>Нуок
Мне вот удивительно, как человек с такой верой в непогрешимость собственных суждений умудряется еще и узнавать что-то новое. Хотя...
Здравствуйте, so5team, Вы писали:
S>Я это к тому, что в C++, исторически, всратая система информирования об ошибках и это не имеет прямое отношения к шаблонам.
Утиная типизация в шаблонах дополнительно усложняет диагностику. Ты получаешь лог об ошибке вообще не в том месте где она действительно возникла. Вместо простого и понятного что такой-то тип не подходит по условиям для подстановки в такойто шаблон
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Утиная типизация в шаблонах дополнительно усложняет диагностику.
Добавлю отдельно: основная проблема утиной типизации в шаблонах (как по мне, это все злостное имхо) не в проблемах диагностики если в шаблон отдали что-то не то. А в том, что здесь как в динамически типизированных языках: пока все тестами не покроешь, нет никакой уверенности. Даже в том, что шаблон вообще скомпилируется. Раньше вон VC++ допускал наличие в теле шаблона синтаксических ошибок -- там просто транслятор был так устроен, что если шаблон не инстанциируется, то его тело толком и не парсилось.
Вот это да, это гораздо серьезнее. Напишешь шаблонный код, который отлично работает с X и const X &, через года полтора кто-то в него засунет X && и бах! Ошибка компиляции, а автор шаблона уже и сам не помнит, всех деталей.
Здравствуйте, CreatorCray, Вы писали:
S>>Мне уже столько раз сообщали, что я не умею писать код, ничего не понимаю в разработке, застрял в 1990-х и вообще идиот CC>И? Я то к этому всему каким боком?
Т.е. вот этот намек сделали не вы: "но ты лучше отойди от зеркала что ли..."?
Если не вы, то извините.
Если вы, то напрасно теряете время, есть у меня ощущение, что в свой адрес я уже успел выслушать больше гадостей, чем вы сможете исполнить даже если поставите перед собой цель.
S>> что вы точно к этому списку ничего не добавите. S>>К непогрешимости суждений добавляется еще и раздутое самомнение. CC>Ты правда думаешь что меня интересует твоя персона?
Очень надеюсь, что нет.
CC>Я написал про функциональщину,
И я вам ответил, что ваше мнение по поводу функциональщины попахивает ретроградщиной и лудизмом. Вы подтверждаете это впечатление приводя левые аналоги вместо нормальных аргументов о том, почему функциональщина в C++ -- это плохо. Что очень смахивает на доказательства из категории "Потому что я так сказал".
CC>ты же перевёл это всё строго на себя.
Значит все-таки это не вы писали фразу "но ты лучше отойди от зеркала что ли..." и относилась она не ко мне. Ну OK, если так.
Здравствуйте, T4r4sB, Вы писали:
TB> R>Штука в том, что не начни авторы "правильных языков" проект на сишечке, небыло бы никаких "правильных языков".
TB> Ну а авторы сишечки писали компилятор на чемто еще более древнем, скорее всего ассемблере. И что?
Здравствуйте, CreatorCray, Вы писали:
S>>почему функциональщина в C++ -- это плохо. CC>Потому что не надо из императивного языка изобретать что то другое. Бери функциональный язык и пиши на нём.
А можно подробнее? Вот я на C# привык писать подобные и даже покруче Ling-запросы. И не вижу что С++ чем-то сильно хуже по синтаксису. Вообще не вижу проблем в том коде, которые привели — все вроде чисто, все ясно.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
КБ>>Только 2023й год, только опенсорс, только ошибки работы с памятью
S>И какова там доля C++?
Понятия не имею. Да и не важно это.
У вас же еще не появился флаг компилятора разрешающий только безопасное подмножество C++?
А будете вы писать мимо буфера через char * или через std::vector совершенно не принципиально.
Здравствуйте, B0FEE664, Вы писали: BFE>Здравствуйте, Константин Б., Вы писали: C>>>>>А причем тут вирус-шифровальщик и языки программрования? Какая между ними связь? КБ>>>>Код на си — ошибки работы с памятью — уязвимости — ransomware. BFE>>>Доказательства? КБ>>Только 2023й год, только опенсорс, только ошибки работы с памятью BFE>А можно такой же список на альтернативных языках?
Можно. Список уязвимостей вызванными ошибками работы с памятью на rust, c#, java, js, PHP:
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Разраб, Вы писали:
Р>>не хуже на мой взгляд чем это CC>Тут какой то псих пишет LINQ-style кашу.
ну как псих. The Reactive Extensions for Native (RxCpp) is a library for composing asynchronous and event-based programs using observable sequences and LINQ-style query operators in both C and C++.
, те что в десятке мэйнстримных языков реализованы.
Я к тому, что не язык определяет человека, а наоборот.
Вот для меня кол-во концепций ++ слишком велико.
В расте хотя бы инструменты единые, понятные сообщения компилятора.
а ++ я даже не понял какие нужны чтобы модули заюзать под линуксом.
а по синтаксису они могут соревноваться.
Здравствуйте, CreatorCray, Вы писали:
CC>>>Тут какой то псих пишет LINQ-style кашу. Р>>ну как псих. CC>На С++ писать функциональщину — это mental disorder
А что там такого ужасного? Разница лишь в форме записи и к этому можно привыкнуть.
Здравствуйте, Shmj, Вы писали:
S>Мое недовольство было — по количеству бойлерплейт кода.
Покажи аналог на С++. Чтоб в заголовке шаблона были описаны все необходимые и достаточные ограничения на типы, которые в него можно подставлять (кажется, "концепт" называется).
Просто утиный шаблон не предлагать, потому что нечитаемых ошибок компиляции от govno compiler collection я насмотрелся.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, vsb, Вы писали:
vsb>Напиши тот же код на другом языке со сходными возможностями. C++ или Haskell. И тогда можно попробовать сравнить. vsb>По сути тут задача не тривиальная же.
Здравствуйте, Shmj, Вы писали:
S>А что там такого ужасного? Разница лишь в форме записи и к этому можно привыкнуть.
Это примерно как define нафигачить и на плюсах писать как на паскале, с begin/end.
Работать то будет, но нафига???
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, T4r4sB, Вы писали:
TB>Покажи аналог на С++. Чтоб в заголовке шаблона были описаны все необходимые и достаточные ограничения на типы, которые в него можно подставлять (кажется, "концепт" называется). TB>Просто утиный шаблон не предлагать,
Есть принципиальная разница: в Rust-е все эти ограничения формально необходимы. В C++ -- нет, до тех пор пока концепты (или SFINAE до C++20) не потребуются для выбора одной из нескольких перегрузок average в зависимости от параметров.
TB> потому что нечитаемых ошибок компиляции от govno compiler collection я насмотрелся.
Здравствуйте, kov_serg, Вы писали:
vsb>>Напиши тот же код на другом языке со сходными возможностями. C++ или Haskell. И тогда можно попробовать сравнить. vsb>>По сути тут задача не тривиальная же.
_>o_O вычисление среднего не тривиальная задача?
В типизированном языке, для произвольных типов и с адекватными сообщениями об ошибках при неправильном использовании — я думаю, что не тривиальная.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, CreatorCray, Вы писали:
CC>>>>Тут какой то псих пишет LINQ-style кашу. Р>>>ну как псих. CC>>На С++ писать функциональщину — это mental disorder
S>А что там такого ужасного? Разница лишь в форме записи и к этому можно привыкнуть.
Вообщем идея хорошая, но что-то вам мешает.
Тут просто надо выбрать: путь одиночки или со стадом.
S>Каким-то ретроградством и лудизмом пахнуло.
Каким-то хомячизмом и доверчивостью к мнению большинства пахнуло. А если принять во внимание тот факт, что функциональщина — это древняя откопанная стюардесса, то кто еще тут ретроград?
Здравствуйте, so5team, Вы писали:
S>Есть принципиальная разница: в Rust-е все эти ограничения формально необходимы. В C++ -- нет,
И это минус С++.
TB>> потому что нечитаемых ошибок компиляции от govno compiler collection я насмотрелся.
S>Вас пожалеть?
Нет, только не надо врать, как легко и классно ты за минуту понимаешь, почему на шаблонном коде govno compiler collection высирает тупое бесполезное эссе на 1000 строк какого-то бреда, в котором нет ни единого упоминания строчки, где действительно произошла ошибка.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, so5team, Вы писали:
S>Нет, ретроградство и лудизм -- это ассоциировать функциональщину в C++ с забиванием гвоздей перфоратором.
Что одно что другое — использование мощного инструмента не по назначению.
S>Мне вот удивительно, как человек с такой верой в непогрешимость собственных суждений умудряется еще и узнавать что-то новое. Хотя...
Рад тебе сообщить что то новое, но ты лучше отойди от зеркала что ли...
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, T4r4sB, Вы писали:
S>>Я это к тому, что в C++, исторически, всратая система информирования об ошибках и это не имеет прямое отношения к шаблонам.
TB>Утиная типизация в шаблонах дополнительно усложняет диагностику. Ты получаешь лог об ошибке вообще не в том месте где она действительно возникла. Вместо простого и понятного что такой-то тип не подходит по условиям для подстановки в такойто шаблон
По моим наблюдениям сейчас уже гораздо получше. Где-то начиная с gcc-9.
А вот то, что C++ компиляторы вместо того, чтобы остановиться не первой найденной проблеме пытаются идти дальше и вываливают еще 100500 сообщений о последующих ошибках... Вот это 3.14дец, простите мне мой французский. Пишешь класс, забываешь после него точку с запятой поставить, ниже по коду используешь его в качестве параметра шаблона и... В выхлопе сперва то, что мне нужно, а потом еще 10 страниц с ошибками о том, как компилятор пытался инстанциировать шаблон, но не смог + информация о том, как он пытался это делать.
Здравствуйте, so5team, Вы писали:
S>Мне уже столько раз сообщали, что я не умею писать код, ничего не понимаю в разработке, застрял в 1990-х и вообще идиот
И? Я то к этому всему каким боком?
S> что вы точно к этому списку ничего не добавите. S>К непогрешимости суждений добавляется еще и раздутое самомнение.
Ты правда думаешь что меня интересует твоя персона?
Я написал про функциональщину, ты же перевёл это всё строго на себя.
Так что самомнение твоё таки да, походу раздутое.
Сдувай.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>И я вам ответил, что ваше мнение по поводу функциональщины попахивает ретроградщиной и лудизмом.
Ты читать умеешь?
Написано же: "На С++ писать функциональщину..."
S>почему функциональщина в C++ -- это плохо.
Потому что не надо из императивного языка изобретать что то другое. Бери функциональный язык и пиши на нём.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>И я вам ответил, что ваше мнение по поводу функциональщины попахивает ретроградщиной и лудизмом. CC>Ты читать умеешь? CC>Написано же: "На С++ писать функциональщину..."
Я ни на шаг не отошел от темы "функциональщины на C++", поэтому не вижу смысла в каждом упоминании "функциональщины" добавлять еще и "C++"
S>>почему функциональщина в C++ -- это плохо. CC>Потому что не надо из императивного языка изобретать что то другое.
И почему?
Позволю себе напомнить, что C++ мультипарадигменный язык и программирование на шаблонах C++ начиная с C++98 возможно именно в функциональном стиле.
CC>Бери функциональный язык и пиши на нём.
Это такой же аргумент, как и "На С++ писать функциональщину — это mental disorder". Т.е. и не аргумент вовсе.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Константин Б., Вы писали:
КБ>> В чястности не надо начинать новые проекты на сишечке, чтобы количество уязвимостей хотя бы не росло.
R>Штука в том, что не начни авторы "правильных языков" проект на сишечке, небыло бы никаких "правильных языков".
Ну даже допустим что это правда (что конечно же нет, обычно новые языки на каком-нить окамле бустрапят).
И что с того?
Часто вижу этот аргумент что типа компилятор — это что-то низкоуровневое что кроме как на сишечке не написать.
И если хоть немного подумать то это конечно же чушь.
Компилятор — это програма считывающая один файл, и выдающая другой. Т.е. нечто максимально прикладное, высокоуровневое, максимально далекое от железа.
Здравствуйте, Константин Б., Вы писали: КБ>Да. К сожалению если программу на нормальном языке запускать на платформе написанной на сишечке — то уровень безопасности будет как у сишечки.
Очень, очень странное утверждение. А если программу на нормальном языке запустить на процессоре, исполняющем интеловский набор инструкций, то уровень безопасности будет как у интеловского набора инструкций? КБ>Это как строить небоскребы на заминированном болоте вместо фундамента.
Нет. Это как делать надёжные решения из ненадёжных компонентов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Константин Б., Вы писали: КБ>>Да. К сожалению если программу на нормальном языке запускать на платформе написанной на сишечке — то уровень безопасности будет как у сишечки. S>Очень, очень странное утверждение. А если программу на нормальном языке запустить на процессоре, исполняющем интеловский набор инструкций, то уровень безопасности будет как у интеловского набора инструкций?
Я не знаю что означает "безопасности будет как у интеловского набора инструкций".
Но если ты про те уязвимости что были обнаружены в процессорах интел и амд — то да, они пускают насмарку всю вышестоящую безопасность.
КБ>>Это как строить небоскребы на заминированном болоте вместо фундамента. S>Нет. Это как делать надёжные решения из ненадёжных компонентов.
Безопасность и надежность это совершенно разные понятия.
Здравствуйте, Константин Б., Вы писали:
C>>А причем тут вирус-шифровальщик и языки программрования? Какая между ними связь? КБ>Код на си — ошибки работы с памятью — уязвимости — ransomware.
Здравствуйте, Константин Б., Вы писали:
КБ>Я не знаю что означает "безопасности будет как у интеловского набора инструкций".
Имеется в виду "такая же безопасность, как если исполнять программу, написанную на ассемблере". КБ>Но если ты про те уязвимости что были обнаружены в процессорах интел и амд — то да, они пускают насмарку всю вышестоящую безопасность.
Как интересно. И зачем же тогда выходили всякие патчи для ОС, закрывающие уязвимости интел и амд? Ну, раз безопасность один хрен определяется нижележащей платформой.
Кстати, наверное безопасность интела — она примерно такая же, как у отдельных транзисторов, из которых он состоит? КБ>>>Это как строить небоскребы на заминированном болоте вместо фундамента. S>>Нет. Это как делать надёжные решения из ненадёжных компонентов. КБ>Безопасность и надежность это совершенно разные понятия.
Но общий принцип остаётся примерно тем же. Вас же не смущает TLS-коммуникация поверх незащищённого канала.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Константин Б., Вы писали:
C>>>А причем тут вирус-шифровальщик и языки программрования? Какая между ними связь? КБ>>Код на си — ошибки работы с памятью — уязвимости — ransomware.
BFE>Доказательства?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
КБ>>Я не знаю что означает "безопасности будет как у интеловского набора инструкций". S>Имеется в виду "такая же безопасность, как если исполнять программу, написанную на ассемблере".
Тогда ответ — нет.
Похоже суть проблемы не понята.
Вопрос в том как получен этот набор инструкций.
Есть компиляторы которые гарантируют правильную работу с памятью. А есть такие которые перекладывают эту ответственность на кожаных мешков. А кожанные мешки склонны ошибаться.
В программе на шарпе например проехаться по памяти вроде как нельзя. Но если вызывать системное API написанное на сишечке — то тогда все гарантии теряются.
КБ>>Но если ты про те уязвимости что были обнаружены в процессорах интел и амд — то да, они пускают насмарку всю вышестоящую безопасность. S>Как интересно. И зачем же тогда выходили всякие патчи для ОС, закрывающие уязвимости интел и амд? Ну, раз безопасность один хрен определяется нижележащей платформой.
А вы вообще в курсе что именно эти патчи делают?
S>Но общий принцип остаётся примерно тем же. Вас же не смущает TLS-коммуникация поверх незащищённого канала.
Если она реализована на сишечке то смущает. Heartbleed помните?
Здравствуйте, T4r4sB, Вы писали:
TB>Нет, только не надо врать, как легко и классно ты за минуту понимаешь, почему на шаблонном коде govno compiler collection высирает тупое бесполезное эссе на 1000 строк какого-то бреда, в котором нет ни единого упоминания строчки, где действительно произошла ошибка.
Дарю лайфхак — grep "instantiated from here" или просто "here" в выводе от gcc дает имя файл и номер строки.
Чтобы не получать все ошибки есть
The command-line option -fmax-errors=N directs the compiler to give up after N errors. This option is present in GCC 4.6 and later.
The command-line option -Wfatal-errors directs the compiler to give up after one error. This option is present in GCC 4.0 and later.
In both cases, warnings do not count toward the limit unless you also specify -Werror.
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, T4r4sB, Вы писали:
TB>>Нет, только не надо врать, как легко и классно ты за минуту понимаешь, почему на шаблонном коде govno compiler collection высирает тупое бесполезное эссе на 1000 строк какого-то бреда, в котором нет ни единого упоминания строчки, где действительно произошла ошибка.
PM>Дарю лайфхак — grep "instantiated from here" или просто "here" в выводе от gcc дает имя файл и номер строки.
Govno compiler collection не был бы таким govno если бы он в некоторых случаях вообще не забывал номер проблемной строки. Я честно искал.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Константин Б., Вы писали: КБ>Похоже суть проблемы не понята.
Да, тут явно потеря взаимопонимания.
КБ>Вопрос в том как получен этот набор инструкций.
Именно, именно. КБ>Есть компиляторы которые гарантируют правильную работу с памятью. А есть такие которые перекладывают эту ответственность на кожаных мешков. А кожанные мешки склонны ошибаться.
Именно. Поэтому безопасность программы на ассемблере чуть ниже, чем программы на сишечке.
А безопасность программы на java — чуть выше.
КБ>В программе на шарпе например проехаться по памяти вроде как нельзя. Но если вызывать системное API написанное на сишечке — то тогда все гарантии теряются.
Эмм, вообще-то если вызвать из любого языка системное (да и вообще любое) API, написанное "на сишечке" — то все гарантии теряются.
Это никак не связано с тем, на каком языке написан рантайм этого языка. Если, к примеру, убрать из шарпа PInvoke, то без ключика /unsafe проехаться по памяти в нём станет нельзя.
Отсюда имеем, к примеру, Singularity, где 100% кода верифицировано. И опять-таки, ядро сингуларити написано не на C#; тем не менее, её безопасность от этого не страдает.
КБ>А вы вообще в курсе что именно эти патчи делают?
Отож. S>>Но общий принцип остаётся примерно тем же. Вас же не смущает TLS-коммуникация поверх незащищённого канала. КБ>Если она реализована на сишечке то смущает. Heartbleed помните?
Ну что ж вы. Только-только разговор начал становится более-менее конструктивным, и такое шулерство.
Вопрос не в том, на чём написанкод TLS-коммуникации, а в том, что канал, по которому едут байты, вполне может быть скомпрометирован.
Это совершенно ортогонально реализации. Я могу написать клиент и сервер на любом, сколь угодно безопасном языке программирования; но если я буду обмениваться между ними нешифрованным неподписанным трафиком — то никакой безопасности не получится.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
КБ>>В программе на шарпе например проехаться по памяти вроде как нельзя. Но если вызывать системное API написанное на сишечке — то тогда все гарантии теряются. S>Эмм, вообще-то если вызвать из любого языка системное (да и вообще любое) API, написанное "на сишечке" — то все гарантии теряются.
Ну т.е. с моим утверждением ты согласен. Но тебе хочется обсудить что-то свое и ты приписываешь мне всякий бред?
S>>>Но общий принцип остаётся примерно тем же. Вас же не смущает TLS-коммуникация поверх незащищённого канала. КБ>>Если она реализована на сишечке то смущает. Heartbleed помните? S>Ну что ж вы. Только-только разговор начал становится более-менее конструктивным, и такое шулерство.
Шулерство в том что я не даю сменить тему и приписать мне бред? Ну ок.
Здравствуйте, Константин Б., Вы писали: КБ>Ну т.е. с моим утверждением ты согласен.
Смотря с каким.
С утверждением про отсутствие гарантий при вызове PInvoke — согласен.
А вот с исходным утверждением:
К сожалению если программу на нормальном языке запускать на платформе написанной на сишечке — то уровень безопасности будет как у сишечки
— не согласен.
Либо я его неверно понимаю, либо оно ошибочно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Константин Б., Вы писали:
C>>>А причем тут вирус-шифровальщик и языки программрования? Какая между ними связь? КБ>>Код на си — ошибки работы с памятью — уязвимости — ransomware.
BFE>Доказательства?
Только 2023й год, только опенсорс, только ошибки работы с памятью
Здравствуйте, T4r4sB, Вы писали:
TB>https://godbolt.org/z/8bKfe8nxr TB>где в этом бесполезном эссе от govno compiler collection упоминается строка номер 6, в которой я пытаюсь скопировать объект, для которого копирование невозможно?
Справедливости ради на строку №6 не указал ни один из компиляторов большой тройки (gcc, clang, msvc).
Здравствуйте, Константин Б., Вы писали:
S>>И какова там доля C++?
КБ>Понятия не имею. Да и не важно это.
Важно.
КБ>У вас же еще не появился флаг компилятора разрешающий только безопасное подмножество C++?
Его не существует (ну если только в узких рамках constexpr/constinit когда код исполняется в compile-time).
КБ>А будете вы писать мимо буфера через char * или через std::vector совершенно не принципиально.
Дело не в этом, а в том, что в Си в принципе многие вещи невыразимы. Например, в C++ можно ввести тип valid_index и сделать код, который вместо int/size_t оперирует valid_index. Тогда как в Си все будет держаться на честном слове.
В C++ вы можете сделать optional, expected и variant, которые будут проверять попытки доступа к содержимому и платить вы будете только за эти проверки, все остальное будет эффективно. В Си этого не получится.
И т.д., и т.п.
Т.е., потенциально, на C++ можно писать более надежный и безопасный код, чем на Си.
Но Си и C++ все еще продолжают смешивать в одну кучу. Приводя в доказательство список уязвимостей в коде на чистом Си.
Здравствуйте, T4r4sB, Вы писали:
PM>>Дарю лайфхак — grep "instantiated from here" или просто "here" в выводе от gcc дает имя файл и номер строки.
TB>Вот конкретный пример: TB>https://godbolt.org/z/8bKfe8nxr TB>где в этом бесполезном эссе от govno compiler collection упоминается строка номер 6, в которой я пытаюсь скопировать объект, для которого копирование невозможно? TB>А в реальной консоли это эссе в разы длиннее, потому что эти мега-длинные строки переносятся на десять.
Хм, да GCC в этом случае заслуживает альтернативное название от тебя.
Может быть, дело в особенностях GCC реализации стандартной библиотеки? Вызов clang c ключом `-stdlib=libc++` дает вывод получше:
In file included from <source>:1:
In file included from /opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/unordered_map:435:
In file included from /opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/__hash_table:15:
/opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/memory:911:28: error: call to implicitly-deleted copy constructor of 'std::pair<const int, std::unique_ptr<int>>'
::new ((void*)__p) _Up(_VSTD::forward<_Args>(__args)...);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/__memory/allocator_traits.h:288:13: note: in instantiation of function template specialization 'std::allocator<std::__hash_node<std::__hash_value_type<int, std::unique_ptr<int>>, void *>>::construct<std::pair<const int, std::unique_ptr<int>>, const std::pair<const int, std::unique_ptr<int>> &>' requested here
__a.construct(__p, _VSTD::forward<_Args>(__args)...);
^
/opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/__hash_table:2473:20: note: in instantiation of function template specialization 'std::allocator_traits<std::allocator<std::__hash_node<std::__hash_value_type<int, std::unique_ptr<int>>, void *>>>::construct<std::pair<const int, std::unique_ptr<int>>, const std::pair<const int, std::unique_ptr<int>> &, void>' requested here
__node_traits::construct(__na, _NodeTypes::__get_ptr(__h->__value_),
^
/opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/__hash_table:2093:29: note: in instantiation of function template specialization 'std::__hash_table<std::__hash_value_type<int, std::unique_ptr<int>>, std::__unordered_map_hasher<int, std::__hash_value_type<int, std::unique_ptr<int>>, std::hash<int>, std::equal_to<int>, true>, std::__unordered_map_equal<int, std::__hash_value_type<int, std::unique_ptr<int>>, std::equal_to<int>, std::hash<int>, true>, std::allocator<std::__hash_value_type<int, std::unique_ptr<int>>>>::__construct_node_hash<const std::pair<const int, std::unique_ptr<int>> &>' requested here
__node_holder __h = __construct_node_hash(__hash, _VSTD::forward<_Args>(__args)...);
^
/opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/__hash_table:1154:16: note: in instantiation of function template specialization 'std::__hash_table<std::__hash_value_type<int, std::unique_ptr<int>>, std::__unordered_map_hasher<int, std::__hash_value_type<int, std::unique_ptr<int>>, std::hash<int>, std::equal_to<int>, true>, std::__unordered_map_equal<int, std::__hash_value_type<int, std::unique_ptr<int>>, std::equal_to<int>, std::hash<int>, true>, std::allocator<std::__hash_value_type<int, std::unique_ptr<int>>>>::__emplace_unique_key_args<int, const std::pair<const int, std::unique_ptr<int>> &>' requested here
return __emplace_unique_key_args(_NodeTypes::__get_key(__x), __x);
^
/opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/unordered_map:1731:18: note: in instantiation of member function 'std::__hash_table<std::__hash_value_type<int, std::unique_ptr<int>>, std::__unordered_map_hasher<int, std::__hash_value_type<int, std::unique_ptr<int>>, std::hash<int>, std::equal_to<int>, true>, std::__unordered_map_equal<int, std::__hash_value_type<int, std::unique_ptr<int>>, std::equal_to<int>, std::hash<int>, true>, std::allocator<std::__hash_value_type<int, std::unique_ptr<int>>>>::__insert_unique' requested here
__table_.__insert_unique(*__first);
^
/opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/unordered_map:1613:5: note: in instantiation of function template specialization 'std::unordered_map<int, std::unique_ptr<int>>::insert<std::__hash_map_const_iterator<std::__hash_const_iterator<std::__hash_node<std::__hash_value_type<int, std::unique_ptr<int>>, void *> *>>>' requested here
insert(__u.begin(), __u.end());
^ <source>:6:14: note: in instantiation of member function 'std::unordered_map<int, std::unique_ptr<int>>::unordered_map' requested here
auto b = a;
^
/opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/utility:309:5: note: explicitly defaulted function was implicitly deleted here
pair(pair const&) = default;
^
/opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/utility:306:9: note: copy constructor of 'pair<const int, std::unique_ptr<int>>' is implicitly deleted because field 'second' has a deleted copy constructor
_T2 second;
^
/opt/compiler-explorer/clang-12.0.1/bin/../include/c++/v1/memory:1579:3: note: copy constructor is implicitly deleted because 'unique_ptr<int>' has a user-declared move constructor
unique_ptr(unique_ptr&& __u) _NOEXCEPT
^
1 error generated.
Compiler returned: 1
Здравствуйте, Константин Б., Вы писали:
C>>>>А причем тут вирус-шифровальщик и языки программрования? Какая между ними связь? КБ>>>Код на си — ошибки работы с памятью — уязвимости — ransomware. BFE>>Доказательства? КБ>В базе CVE.
Как там сделать выборку по языку?
Здравствуйте, Константин Б., Вы писали: C>>>>А причем тут вирус-шифровальщик и языки программрования? Какая между ними связь? КБ>>>Код на си — ошибки работы с памятью — уязвимости — ransomware. BFE>>Доказательства? КБ>Только 2023й год, только опенсорс, только ошибки работы с памятью
А можно такой же список на альтернативных языках?
Здравствуйте, Константин Б., Вы писали: КБ> BFE>А можно такой же список на альтернативных языках? КБ> Можно. Список уязвимостей вызванными ошибками работы с памятью на rust, c#, java, js, PHP: КБ>
Скрытый текст
КБ> — Конец списка.
Ха-ха. Я как-то тут давал ссылки на дыры в дотнете. А это, заметь, сильно-сильно хуже, чем дыра в софте Васи Пупкина.
Здравствуйте, Константин Б., Вы писали: BFE>>А можно такой же список на альтернативных языках? КБ>Можно. Список уязвимостей вызванными ошибками работы с памятью на rust, c#, java, js, PHP: КБ>
Скрытый текст
КБ>- Конец списка.
Не верю. У меня от js много раз падали различные браузеры.
А от нехватки памяти падали Java приложения.
Ладно, а список уязвимостей не связанных с памятью? Есть такой?