Pull to refresh
16
0

Пользователь

Send message

Продолжай верить в деда мороза.

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

предложил вариант со специальной инструкцией SSE4

и как же она будет работать не выходя за границу? =)

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

Нельзя. С точки зрения стандарта по адресу лежит какой-то обьект, не так важно через какие касты указателей в к нему добираетесь важно чтобы читался тот же обьект что и был записан изначально. Есть исключения для signed в unsigned, based в derived и испектирование репрезентации через std::byte. На самом деле по стандарту даже malloc либо до недавнего времени, либо до сих пор использовать нельзя. Поэтому полезность такого стандарта близка к нулю.

Как раз unsigned char на ровне с std::byte может быть использован для доступа к репрезентации обьекта.

так это были строки или числа?

Но это не является основной проблемой, там в iostream есть похуже тормоза, какие то локи, для флоатов локали (?), и под виндой их (было?) больше. Вообщем каким-то образом автор пришёл к сишным функциям 15 лет назад =)

Проблема cin и cout (правдая было или не было автор уже не помнит). Решение

Я тупо переходил на C и Java в таких случаях.

Т.е. то что printf и scanf можно использовать из С++ вы не знали, и не знаете до сих пор? :) Про то что С++ позволяет вам напрямую работать с файлами если вам действительно нужен быстрый вывод, я уже молчу. Но вообще msvc известен своей криворукостью.

Какой-то индусский код. Сделали бы просто список расширений и всё. Потом можно было бы сделать `assert(is_unique(extensions_list))`. Хотя дублированное расширение в этом списке к ошибки не приводит, просто борьба за аккуратность кода.

А возможно этот весь список просто из разных источников. тогда следовало просто сделать два списка `extenssions_a` и `extensions_b` тогда и мержить их предварительно смысла нету, если это проверка ничего по времени не занимает. В итоге ваше исправление могло сделать только хуже.

В C и C++ ещё со стародавних времён argc не может быть равным 0.

а теперь сходите по ссылке на уязвимость polkit, ну и можете ещё в стандарт Си/Си++ заглянуть если хочется, или POSIX.

Любому кто видел командную строку юникс или Powershell пайп вида `cat x | grep y` точно так же понятен.

Нет такого ТЗ.

Ок, можно было скопировать в новый массив и передать его в execv.

Ок, проверка в `peekArray` есть, это хорошо. Я быстрым гуглением только `getArgs` посмотрел и там было вот это `p - 1` и сразу advancePtr подозрительное.

Насчёт FFI, то что его объявить легко это один вопрос, но другой вопрос что у вас указатели продолжают гулять по коду до момента преобразования в `[String]`. Т.е. уже после этого есть какой-то профит от высокоуровновсти языка, до этого это всё ещё код для связи с Си.

считать кривой String вы сможете, а вот записать в него — уже нет иммутабельность же.

Это замечательно, но по ТЗ как раз надо записать, о чём я и говорил.

Гетопт не сильно лучше, да и вообще не то наверное.

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

Зы. Что там хаскель код глянули? Я там проверку на argc != 0 не вижу.

Добавлю насчёт гетопт. Вообщем смылс того кода в pkexec, чтобы перезаписать argv[0]. И вряд-ли либы стандартные в языках дают такую возможность. Уже объект к нам придет из языка, а нужен сырой указатель.

в 2009-ом ещё и модерн С++ толком не было, другие языки что вы перечислили тоже вряд ли были. Ошибка в коде на Си, и вы зря инронизируете, она вызвана недостатком абстракций. Так устроена ОС, которой лет ещё больше, что аргументы приходят в формате argc/argv. Соответсвенно где-то это реализация должна быть. И такую же ошибку можно было бы допустить где угодно, если неправильно понять что первый аргумент может быть нулл (или в чём там ошибка). Например её можно совершить при реализации библиотечной функции getArgs в хаскель (кстати проверте на всякий случай что там - выглядит немного подозрительно - но я хаскель не знаю). Но, были бы абстракции, парсинг аргументов происходил бы только один раз в стандартной либе, вместо того чтобы делать его в каждой программе на си. Это позволило бы выявить уязвимость раньше, и исправить её сразу у всех. Но у polkit всё сложнее, потому что эта утилита должна со всеми этими аргументами, переменными окружения, fork/exec работать достаточно много, т.е. получается это и есть аналог стандартной библиотеки для управления политиками безопасности. Кроме того, выбор си может быть обусловлен тем, что надо предоставлять си-интерфейс чтобы polkit можно было использовать из других языков.

Тот же електрон, тоже интересный пример. Потому что Javascript довольно отвратительный язык, но так исторически сложилось что в него влили много ресурсов и на сам веб движок и на кое какие либы и на подготовку кадров. В итоге получается отрасль с него слезть не может.

Вообщем там где выбирают електрон, там плюсы выбирать не надо. А там где выбирают С++, там выбрать Си+прувер не получается. Как-то так.

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

На самом деле проблема такого подхода возникает когда есть много разных ошибок. Например изначально есть ошибки A, B, C, D. Дальше есть функция x(), которая вызывает функции с потенциальными ошибками A, B и функция y(), которая вызвает ошибки с вариантами A, C, D. Впринципе можно предположить что A это какая-то ошибка более частая - то же io, а B, C, D что то более конкретное доменное. Воощем в итоге получается что у нас `enum X { A, B }` и `enum Y { A, C, D }`. потом появляется функция z() которая вызывает x()? и y()? ... Хорошо делаем дальше `enum Z { X, Y }`... В итоге чтобы найти в этой иерархии наш начальный A приходится ходить внутрь дерева енумов 10ью разными путями. Сделать из дерева плоскую форму ошибок, перегруппировать её, - таких средств нам раст не даёт. Вообщем на третьем-четвёртом уровне вложености всем надоедает, и делают dyn Box (которого вы обещали что не будет)... Люди пишут блоги с какими-то мантрами про то когда на самом деле нужно боксить а когда нет, наплодили десяток либ с макросами, чтобы упростить эту лапшу енумов с From, match и map_err. А в итоге среднестатистческий код на расте не состоит на 90% из обработки ошибок, лишь потому, что используется механизм исключений из С++ спрятанный за макросом panic!.

Один бокс потенциально есть внутри

std::io::Error

Макрос тоже есть в первой строчки вашего снипетта ;) Но писать эти строки с From обычно лень и берут `thiserror` макрос.

Information

Rating
Does not participate
Registered
Activity