Тот же strict-aliasing он не пришёл внезапно, поэтому не вижу большой проблемы следить за такого рода breaking change в компиляторах. Тем более что strlen так просто не пропадёт, и он должен остаться производительный, а значит и этот подход будет работать.
Нельзя. С точки зрения стандарта по адресу лежит какой-то обьект, не так важно через какие касты указателей в к нему добираетесь важно чтобы читался тот же обьект что и был записан изначально. Есть исключения для signed в unsigned, based в derived и испектирование репрезентации через std::byte. На самом деле по стандарту даже malloc либо до недавнего времени, либо до сих пор использовать нельзя. Поэтому полезность такого стандарта близка к нулю.
Но это не является основной проблемой, там в iostream есть похуже тормоза, какие то локи, для флоатов локали (?), и под виндой их (было?) больше. Вообщем каким-то образом автор пришёл к сишным функциям 15 лет назад =)
Проблема cin и cout (правдая было или не было автор уже не помнит). Решение
Я тупо переходил на C и Java в таких случаях.
Т.е. то что printf и scanf можно использовать из С++ вы не знали, и не знаете до сих пор? :) Про то что С++ позволяет вам напрямую работать с файлами если вам действительно нужен быстрый вывод, я уже молчу. Но вообще msvc известен своей криворукостью.
Какой-то индусский код. Сделали бы просто список расширений и всё. Потом можно было бы сделать `assert(is_unique(extensions_list))`. Хотя дублированное расширение в этом списке к ошибки не приводит, просто борьба за аккуратность кода.
А возможно этот весь список просто из разных источников. тогда следовало просто сделать два списка `extenssions_a` и `extensions_b` тогда и мержить их предварительно смысла нету, если это проверка ничего по времени не занимает. В итоге ваше исправление могло сделать только хуже.
Ок, проверка в `peekArray` есть, это хорошо. Я быстрым гуглением только `getArgs` посмотрел и там было вот это `p - 1` и сразу advancePtr подозрительное.
Насчёт FFI, то что его объявить легко это один вопрос, но другой вопрос что у вас указатели продолжают гулять по коду до момента преобразования в `[String]`. Т.е. уже после этого есть какой-то профит от высокоуровновсти языка, до этого это всё ещё код для связи с Си.
считать кривой String вы сможете, а вот записать в него — уже нет иммутабельность же.
Это замечательно, но по ТЗ как раз надо записать, о чём я и говорил.
Гетопт не сильно лучше, да и вообще не то наверное.
Сишный интерфейс можно предоставить, но тогда у вас в коде будет значительную часть занимать конверсия из/в си, и гарантии языка будут завязаны на эту конверсию. Так что для небольшого кода профита мало.
Зы. Что там хаскель код глянули? Я там проверку на argc != 0 не вижу.
Добавлю насчёт гетопт. Вообщем смылс того кода в pkexec, чтобы перезаписать argv[0]. И вряд-ли либы стандартные в языках дают такую возможность. Уже объект к нам придет из языка, а нужен сырой указатель.
в 2009-ом ещё и модерн С++ толком не было, другие языки что вы перечислили тоже вряд ли были. Ошибка в коде на Си, и вы зря инронизируете, она вызвана недостатком абстракций. Так устроена ОС, которой лет ещё больше, что аргументы приходят в формате argc/argv. Соответсвенно где-то это реализация должна быть. И такую же ошибку можно было бы допустить где угодно, если неправильно понять что первый аргумент может быть нулл (или в чём там ошибка). Например её можно совершить при реализации библиотечной функции getArgs в хаскель (кстати проверте на всякий случай что там - выглядит немного подозрительно - но я хаскель не знаю). Но, были бы абстракции, парсинг аргументов происходил бы только один раз в стандартной либе, вместо того чтобы делать его в каждой программе на си. Это позволило бы выявить уязвимость раньше, и исправить её сразу у всех. Но у polkit всё сложнее, потому что эта утилита должна со всеми этими аргументами, переменными окружения, fork/exec работать достаточно много, т.е. получается это и есть аналог стандартной библиотеки для управления политиками безопасности. Кроме того, выбор си может быть обусловлен тем, что надо предоставлять си-интерфейс чтобы polkit можно было использовать из других языков.
Тот же електрон, тоже интересный пример. Потому что Javascript довольно отвратительный язык, но так исторически сложилось что в него влили много ресурсов и на сам веб движок и на кое какие либы и на подготовку кадров. В итоге получается отрасль с него слезть не может.
Вообщем там где выбирают електрон, там плюсы выбирать не надо. А там где выбирают С++, там выбрать Си+прувер не получается. Как-то так.
то что в документации GCC относится и к Си и к Си++ насколько я могу судить
Есть и обратные примеры, type punning через union. А выигрыш в 20% не нужен если это сломает большую часть кодовых баз.
Что запрещает компилятору доопредeлить UdB до implementation defined и обозначить это в документации?
Продолжай верить в деда мороза.
Да ладно, версия компилятора вышла лет 5 назад, а про стрикт алиасинг разговры уже больше 10 лет назад. Так что какой-то внезапности не наблюдаю.
и как же она будет работать не выходя за границу? =)
Тот же strict-aliasing он не пришёл внезапно, поэтому не вижу большой проблемы следить за такого рода breaking change в компиляторах. Тем более что
strlenтак просто не пропадёт, и он должен остаться производительный, а значит и этот подход будет работать.Нельзя. С точки зрения стандарта по адресу лежит какой-то обьект, не так важно через какие касты указателей в к нему добираетесь важно чтобы читался тот же обьект что и был записан изначально. Есть исключения для signed в unsigned, based в derived и испектирование репрезентации через
std::byte. На самом деле по стандарту дажеmallocлибо до недавнего времени, либо до сих пор использовать нельзя. Поэтому полезность такого стандарта близка к нулю.Как раз
unsigned charна ровне сstd::byteможет быть использован для доступа к репрезентации обьекта.так это были строки или числа?
Но это не является основной проблемой, там в iostream есть похуже тормоза, какие то локи, для флоатов локали (?), и под виндой их (было?) больше. Вообщем каким-то образом автор пришёл к сишным функциям 15 лет назад =)
Проблема
cinиcout(правдая было или не было автор уже не помнит). РешениеТ.е. то что
printfиscanfможно использовать из С++ вы не знали, и не знаете до сих пор? :) Про то что С++ позволяет вам напрямую работать с файлами если вам действительно нужен быстрый вывод, я уже молчу. Но вообще msvc известен своей криворукостью.Какой-то индусский код. Сделали бы просто список расширений и всё. Потом можно было бы сделать `assert(is_unique(extensions_list))`. Хотя дублированное расширение в этом списке к ошибки не приводит, просто борьба за аккуратность кода.
А возможно этот весь список просто из разных источников. тогда следовало просто сделать два списка `extenssions_a` и `extensions_b` тогда и мержить их предварительно смысла нету, если это проверка ничего по времени не занимает. В итоге ваше исправление могло сделать только хуже.
а теперь сходите по ссылке на уязвимость polkit, ну и можете ещё в стандарт Си/Си++ заглянуть если хочется, или POSIX.
Любому кто видел командную строку юникс или Powershell пайп вида `cat x | grep y` точно так же понятен.
Ок, можно было скопировать в новый массив и передать его в execv.
Ок, проверка в `peekArray` есть, это хорошо. Я быстрым гуглением только `getArgs` посмотрел и там было вот это `p - 1` и сразу
advancePtrподозрительное.Насчёт FFI, то что его объявить легко это один вопрос, но другой вопрос что у вас указатели продолжают гулять по коду до момента преобразования в `[String]`. Т.е. уже после этого есть какой-то профит от высокоуровновсти языка, до этого это всё ещё код для связи с Си.
Это замечательно, но по ТЗ как раз надо записать, о чём я и говорил.
Гетопт не сильно лучше, да и вообще не то наверное.
Сишный интерфейс можно предоставить, но тогда у вас в коде будет значительную часть занимать конверсия из/в си, и гарантии языка будут завязаны на эту конверсию. Так что для небольшого кода профита мало.
Зы. Что там хаскель код глянули? Я там проверку на argc != 0 не вижу.
Добавлю насчёт гетопт. Вообщем смылс того кода в pkexec, чтобы перезаписать argv[0]. И вряд-ли либы стандартные в языках дают такую возможность. Уже объект к нам придет из языка, а нужен сырой указатель.
в 2009-ом ещё и модерн С++ толком не было, другие языки что вы перечислили тоже вряд ли были. Ошибка в коде на Си, и вы зря инронизируете, она вызвана недостатком абстракций. Так устроена ОС, которой лет ещё больше, что аргументы приходят в формате argc/argv. Соответсвенно где-то это реализация должна быть. И такую же ошибку можно было бы допустить где угодно, если неправильно понять что первый аргумент может быть нулл (или в чём там ошибка). Например её можно совершить при реализации библиотечной функции
getArgsв хаскель (кстати проверте на всякий случай что там - выглядит немного подозрительно - но я хаскель не знаю). Но, были бы абстракции, парсинг аргументов происходил бы только один раз в стандартной либе, вместо того чтобы делать его в каждой программе на си. Это позволило бы выявить уязвимость раньше, и исправить её сразу у всех. Но у polkit всё сложнее, потому что эта утилита должна со всеми этими аргументами, переменными окружения, fork/exec работать достаточно много, т.е. получается это и есть аналог стандартной библиотеки для управления политиками безопасности. Кроме того, выбор си может быть обусловлен тем, что надо предоставлять си-интерфейс чтобы polkit можно было использовать из других языков.Тот же електрон, тоже интересный пример. Потому что Javascript довольно отвратительный язык, но так исторически сложилось что в него влили много ресурсов и на сам веб движок и на кое какие либы и на подготовку кадров. В итоге получается отрасль с него слезть не может.
Вообщем там где выбирают електрон, там плюсы выбирать не надо. А там где выбирают С++, там выбрать Си+прувер не получается. Как-то так.