и я не сказал, что builtin_unreachable не используется. просто я сомневаюсь, что он действительно делает какие-то крутые оптимизацииэ

!!!! https://godbolt.org/g/UUtYmv

тут же ошибка в условии: '0' <= c && c <= '0'

тут же ошибка в условии: '0' <= c && c <= '0'

Это не ошибка, читай тред полностью

если сделать <= 9, то код становится идентичен

Это не ошибка, читай тред полностью

э... а где читать? ничего не нашел про проверку на 0 таким способом

тут же ошибка в условии: '0' <= c && c <= '0'

Суть в том, что компилятор увидел, что значение, отличное от нуля, не может быть. И соптимизировал до xor eax, eax. Пример немного синтетический, да

а, понял, окей

сначала подумал, что речь именно об контракте [0..9]

Ну на контракте [0; 9] оптимизация не видна, поэтому пришлось костылить

добрый день, кто может помочь разобраться в библиотеке xmlsec ?

добрый день, кто может помочь разобраться в библиотеке xmlsec ?

в чём вопрос?

как получить доступ к алгоритмам гост

пишет not implemented

Видимо собрать с правильными флагами

Видимо собрать с правильными флагами

./configure —help покажет?

Несомненно

спасибо, автоматом конфигуратор вроде находит openssl крипто движок или этого мало?

А в OpenSSL оно включено?

Добрый день, давайте разберемся, как устроена виртуальная память процесса. Понял, что плаваю, а среди коллег никто не плавает лучше. 0. В момент создания, инструкции и константы (в том числе нуллптр) загружаются в защищенную часть. Любая попытка изменения которой приводит к access violation. 1. Помимо этого выделяется участок под стек (10 мб, но может меняться в зависимости от флагов бинарника и оси) и остальное — куча. 2. виртуалка в разделе кучи маппируется в РАМ по мере нужды, это отдельная песня. Под стек и защищенную часть она маппируется сразу, верно? 3. в защищенной части (как она называется правильно?) лежат структуры, функции (те из них, что члены класса и не статичны — имеют скрытый параметр self для передачи указатель на конкретный класс), все варианты виртуальных таблиц, константы, что-то еще? 4. когда в коде дергается метод класса, по его типу в защищенной зоне находится конкретная функция, в которую передается экземпляр конкретного класса первым параметром. 5. если у класса есть виртуальные методы, то указатель на таблицу с виртуальными методами хранится в экземпляре класса. 6. если есть иерархия классов с виртуальными методами, то дочерний тип копирует таблицу родителя, а потом заменяет в ней те методы, которые может. Таким образом в защищенной части памяти процесса будет реально две таблицы. На которые будут ссылаться все экземпляры этих классов. кто-то может дополнить интересным "фактом", который я не заметил, или исправить написанное?

А в OpenSSL оно включено?

да, установлен и проверен гостовский engine

Значит должно быть достаточно, просто включить при сборке

спасибо, сейчас попробую

Значит должно быть достаточно, просто включить при сборке

а не добавляли это дело в Conan?

я смотрю, что вроде либа интересная, хоть и с ужасной билд-системой

Xmlsec вроде нет

Надо запилить

а спонсора так и не нашли?

Добрый день, давайте разберемся, как устроена виртуальная память процесса. Понял, что плаваю, а среди коллег никто не плавает лучше. 0. В момент создания, инструкции и константы (в том числе нуллптр) загружаются в защищенную часть. Любая попытка изменения которой приводит к access violation. 1. Помимо этого выделяется участок под стек (10 мб, но может меняться в зависимости от флагов бинарника и оси) и остальное — куча. 2. виртуалка в разделе кучи маппируется в РАМ по мере нужды, это отдельная песня. Под стек и защищенную часть она маппируется сразу, верно? 3. в защищенной части (как она называется правильно?) лежат структуры, функции (те из них, что члены класса и не статичны — имеют скрытый параметр self для передачи указатель на конкретный класс), все варианты виртуальных таблиц, константы, что-то еще? 4. когда в коде дергается метод класса, по его типу в защищенной зоне находится конкретная функция, в которую передается экземпляр конкретного класса первым параметром. 5. если у класса есть виртуальные методы, то указатель на таблицу с виртуальными методами хранится в экземпляре класса. 6. если есть иерархия классов с виртуальными методами, то дочерний тип копирует таблицу родителя, а потом заменяет в ней те методы, которые может. Таким образом в защищенной части памяти процесса будет реально две таблицы. На которые будут ссылаться все экземпляры этих классов. кто-то может дополнить интересным "фактом", который я не заметил, или исправить написанное?

Если речь про винду - читай про pe format и секции. Права можно выделять только по секциям. Например секции инициализированных данных и неинициализированных данных. Но это уже условности и зависит от конкретного компоновщика. Ничего не мешает все вообще в одну секцию запилить и сделать доступным на запись.

я краем уха слышал, что сейчас в активном поиске, но чот никто не хочет в это деньги вкладывать

я краем уха слышал, что сейчас в активном поиске, но чот никто не хочет в это деньги вкладывать

Хотят под программу мозилы попасть, щас оформляют заявки для неё и ещё нескольких грантов

было бы неплохо. а то там буквально пару человек сидят и пакетят постоянно

И то когда время есть ага

Надо хотя бы одного фул тайм

Спонсорство щас есть для ci пока только

Если речь про винду - читай про pe format и секции. Права можно выделять только по секциям. Например секции инициализированных данных и неинициализированных данных. Но это уже условности и зависит от конкретного компоновщика. Ничего не мешает все вообще в одну секцию запилить и сделать доступным на запись.

спасибо, о каких секциях речь? Т.е. где-то можно позволить процессу подгрузить тела функций в незащищенную область виртуальной памяти?

Обычно код всегда в секции .data с правами page execute read

Но никто не заставляет

А так ничто не мешает подгрузить код из секции данных и выдать права

Какой нибудь upx так примерно и делает

Нужная тебе функция - virtual protect

Читай спецификацию на pe формат, статью об упаковщиках в последний раз, и прочее по теме

Там подробно все рассказывается

спасибо, направление чтения принято =)

Читай спецификацию на pe формат, статью об упаковщиках в последний раз, и прочее по теме

+ если тут есть рейтинги

Добрый день, давайте разберемся, как устроена виртуальная память процесса. Понял, что плаваю, а среди коллег никто не плавает лучше. 0. В момент создания, инструкции и константы (в том числе нуллптр) загружаются в защищенную часть. Любая попытка изменения которой приводит к access violation. 1. Помимо этого выделяется участок под стек (10 мб, но может меняться в зависимости от флагов бинарника и оси) и остальное — куча. 2. виртуалка в разделе кучи маппируется в РАМ по мере нужды, это отдельная песня. Под стек и защищенную часть она маппируется сразу, верно? 3. в защищенной части (как она называется правильно?) лежат структуры, функции (те из них, что члены класса и не статичны — имеют скрытый параметр self для передачи указатель на конкретный класс), все варианты виртуальных таблиц, константы, что-то еще? 4. когда в коде дергается метод класса, по его типу в защищенной зоне находится конкретная функция, в которую передается экземпляр конкретного класса первым параметром. 5. если у класса есть виртуальные методы, то указатель на таблицу с виртуальными методами хранится в экземпляре класса. 6. если есть иерархия классов с виртуальными методами, то дочерний тип копирует таблицу родителя, а потом заменяет в ней те методы, которые может. Таким образом в защищенной части памяти процесса будет реально две таблицы. На которые будут ссылаться все экземпляры этих классов. кто-то может дополнить интересным "фактом", который я не заметил, или исправить написанное?

0. nullptr в защищенной части - это круто сказано. 4. "По типу класса находится конкретная функция" - чушь. Метод с точки зрения скомпилированного кода ничем не отличается от функции с дополнительным аргументом. Идёт самый обычный вызов метода (call какой-нибудь, если привязываться к конкретной реализации). 6. Все эти замены происходят во время компиляции, а после запуска в простейшем случае каждый полиморфный объект хранит указатель на одну из таблиц (в конструкторах/деструкторах идёт перезапись одного поля объекта, а не модификация таблицы).

Есть отдельный чат по бусту?

В Слаке cpplang есть

0. nullptr в защищенной части - это круто сказано. 4. "По типу класса находится конкретная функция" - чушь. Метод с точки зрения скомпилированного кода ничем не отличается от функции с дополнительным аргументом. Идёт самый обычный вызов метода (call какой-нибудь, если привязываться к конкретной реализации). 6. Все эти замены происходят во время компиляции, а после запуска в простейшем случае каждый полиморфный объект хранит указатель на одну из таблиц (в конструкторах/деструкторах идёт перезапись одного поля объекта, а не модификация таблицы).

Спапсибо за развернутый ответ. 0 — а что не так? Стандарт даже гарантирует, что разименование нуллптр-а должно давать эксепшн. Сам он физически разве не среди прочих констант? 4 — принято, а как вообще тогда поиск функций происходит? Там где-то хэш таблица с именами и указателями? И как задают неймспейс (мемберство в классе)? 6 — непонятно возражение: т.е. они *копируют* исходную таблицу, а потом *модифицируют* те поля, которые виртуальные и совпадают по имени + деструктор, если есть. Т.е. модифицируют скопированную таблицу.

Никаких имён нет после компиляции, только адреса

Если только не импорт, тогда да есть таблица адрес-имя

Спапсибо за развернутый ответ. 0 — а что не так? Стандарт даже гарантирует, что разименование нуллптр-а должно давать эксепшн. Сам он физически разве не среди прочих констант? 4 — принято, а как вообще тогда поиск функций происходит? Там где-то хэш таблица с именами и указателями? И как задают неймспейс (мемберство в классе)? 6 — непонятно возражение: т.е. они *копируют* исходную таблицу, а потом *модифицируют* те поля, которые виртуальные и совпадают по имени + деструктор, если есть. Т.е. модифицируют скопированную таблицу.

Насчёт nullptr и эксепшн это не правда же

Там не эксепшн, а undefined behaviour

Имена могут сохраниться только в секции с отладочной информацией но оно не используется для поиска адресов никак

Насчёт nullptr и эксепшн это не правда же

точно, там андеф.

Имена могут сохраниться только в секции с отладочной информацией но оно не используется для поиска адресов никак

т.е. по-сути понятие неймспейса и мемберства класса — это просто абстракции для удобства разработчика, которые никак не отражены в реальном байт-отображении?

Спапсибо за развернутый ответ. 0 — а что не так? Стандарт даже гарантирует, что разименование нуллптр-а должно давать эксепшн. Сам он физически разве не среди прочих констант? 4 — принято, а как вообще тогда поиск функций происходит? Там где-то хэш таблица с именами и указателями? И как задают неймспейс (мемберство в классе)? 6 — непонятно возражение: т.е. они *копируют* исходную таблицу, а потом *модифицируют* те поля, которые виртуальные и совпадают по имени + деструктор, если есть. Т.е. модифицируют скопированную таблицу.

Вы не из питона?) 0. Все числовые константы превращаются в конкретные значения и "вшиваются" в код. Одно дело - это static const int my_value = 1;, но все используемые напрямую в коде (влезающие в регистры) - это готовые числа. int* p = nullptr; -> mov dword [esp + 10], 0 (грубый пример). 4. Как уже написали выше, никаких имён нет после компиляции. Вы себе представляете, куда бы скатилась производительность (в питон), если бы при каждом вызове функции нужен был поиск? Потыкайтесь в дизассемблере, вопросы отпадут. 6. Да, модифицируют копию, но не в рантайме, а в компайл-тайме. На выходе весь оверхед от vtable превращается в парочку операций записи в объект и лишнее чтение памяти при вызове виртуальной функции

Если мы говорим про нативный код - да

Если мы говорим про нативный код - да

*смотрит в название чата*

*смотрит в название чата*

Ну никто не отменял managed c++

Ну никто не отменял managed c++

Отменял, это не си++

Как скажете

Вы не из питона?) 0. Все числовые константы превращаются в конкретные значения и "вшиваются" в код. Одно дело - это static const int my_value = 1;, но все используемые напрямую в коде (влезающие в регистры) - это готовые числа. int* p = nullptr; -> mov dword [esp + 10], 0 (грубый пример). 4. Как уже написали выше, никаких имён нет после компиляции. Вы себе представляете, куда бы скатилась производительность (в питон), если бы при каждом вызове функции нужен был поиск? Потыкайтесь в дизассемблере, вопросы отпадут. 6. Да, модифицируют копию, но не в рантайме, а в компайл-тайме. На выходе весь оверхед от vtable превращается в парочку операций записи в объект и лишнее чтение памяти при вызове виртуальной функции

нет, не из питона. Не владеть подноготной уровня ассемблера очень частое явление, т.к. есть множество вариантов приложения навыков в сях, где просто не возникает необходимости, или она поверхностная. 0. Т.е. nullptr это тот же 0, что и NULL. А нулевой адрес, как водится, находится в защищенной области. Но разве стандарт обязует его быть именно нулем? 6. это да, понятно. Собсно, отсюда и вытекал вопрос: это одна таблица, модифицируемая в райнтайме, или множество таблиц на все возможные варианты, которые в компайл тайме будут сформированы и готовы к работе. Я не знаком с тем, что требует от этого стандарт, и как именно могут изголяться разрабы, но второй вариант очевидно более быстрый и более вероятный.

Никак не требует, на откуп конкретного компилятора

нет, не из питона. Не владеть подноготной уровня ассемблера очень частое явление, т.к. есть множество вариантов приложения навыков в сях, где просто не возникает необходимости, или она поверхностная. 0. Т.е. nullptr это тот же 0, что и NULL. А нулевой адрес, как водится, находится в защищенной области. Но разве стандарт обязует его быть именно нулем? 6. это да, понятно. Собсно, отсюда и вытекал вопрос: это одна таблица, модифицируемая в райнтайме, или множество таблиц на все возможные варианты, которые в компайл тайме будут сформированы и готовы к работе. Я не знаком с тем, что требует от этого стандарт, и как именно могут изголяться разрабы, но второй вариант очевидно более быстрый и более вероятный.

0. Не путайте значение адреса и данные, располагаемые по этому адресу. Память по адресу nullptr является запрещенной для чтения, да. А сам адрес - это просто константа. И она нигде не лежит.

Никак не требует, на откуп конкретного компилятора

про нуллптр? я так и думал, отсюда и было мое предположение, что там не обязательно 0, но что-то, находящееся в защищенной области памяти.

про нуллптр? я так и думал, отсюда и было мое предположение, что там не обязательно 0, но что-то, находящееся в защищенной области памяти.

Про vtable

6. стандарт вроде не описывает конкретную реализацию виртуальных вызовов, но всё что я видел — сформированные на этапе компиляции таблицы и в экземплярах классов указатель на конкретную таблицу.

А нуллптр скорее всего просто подставится и будет в секции кода как часть инструкции, типа mov eax, 0 или даже просто xor eax, eax

Если компилятор совсем деревянный - отляжет в секцию инициализированных данных

/me видел системы где 0 вполне себе такой RW адрес

/me видел системы где 0 вполне себе такой RW адрес

Разыменование 0 - это УБ по стандарту, так что все-равно им не воспользуешься

А нормальное чтение запись в nullptr - просто частный случай ub

Разыменование 0 - это УБ по стандарту, так что все-равно им не воспользуешься

но nullptr ведь не обязан быть нулем же?

не обязан

и может не быть

стандарт лишь требует, чтобы его нельзя было разименовывать. И обычно его делают указывающим на защищенную область памяти (не обязательно по адресу 0), и при разименовании сыперся эксепшн. Или нет?

разыменование nullptr *всегда* UB, разыменование 0 UB (но конкретный компилятор может сделать DB для 0)

Просто ub. Конкретная платформа может в принципе не поддерживать защищённую память и все всегда доступно на запись.

а это вроде не относится к защите и возможности записи

чото сложно, насколько я понял (void *)0 не обязательно прям нуль

разыменование nullptr *всегда* UB, разыменование 0 UB (но конкретный компилятор может сделать DB для 0)

меня давно занимал вопрос, как выкручиваются создатели, например, bootloader'ов, у которых по 0 может лежать какая-нибудь структура, которую нужно разыменовать. Ведь если разыменование 0 - это UB, то компилятор может сгенерировать любой код

в стандарте как-то хитро

На ассемблере можно написать кусок если контроль нужен

вот есть (void *)0, то его приведение к, скажем, (int *)(void *)0 — это UB, то есть до разыменования даже не доходит

На ассемблере можно написать кусок если контроль нужен

это да, но я видел несколько разработок под arm, написанных на СИ89, где разыменовывался нулевой указатель

https://stackoverflow.com/a/48371424

товарищ говорит, что в стандарте должно быть implementation defined для этих случаев, правильно я понял?

то есть (void *)0 == (int *)0 может быть false

ага, я тоже так понял

clang интересная штука: https://godbolt.org/g/iyfN5v

gcc на оба говорит UB, msvc и icc доверяют погромистам =)

/stat@combot

combot.org/c/-1001031904034

gcc на оба говорит UB, msvc и icc доверяют погромистам =)

ub он на то и ub

вообще хотелоь бы, чтобы компиляторы делали намного больше проверок ?

пусть и ценой времени компиляции. но не всё сразу, к сожалению

для avr gcc генерирует норм код. вощем только согласица с товарищем, которые говорит, что это должно быть implementation defined, нежли ub

вообще хотелоь бы, чтобы компиляторы делали намного больше проверок ?

а всякие анализаторы? они как раз долго и упорно ищут, и даже находят

а всякие анализаторы? они как раз долго и упорно ищут, и даже находят

проблема в том, что анализаторы не влияют на генерируемый кодл