AT
в каком случае будет нормальным, что inline static data member получит разные адреса в разных TU?
Size: a a a
2020 March 20
AT
к примеру в хедере есть структура с inline static членами. Она используется в exe-шнике и в dll-ке
AT
это закономерный исход, что произошёл выстрел в ногу?
АК
это закономерный исход, что произошёл выстрел в ногу?
конечно, т.к. у тебя длл и ехе вместе не линкуются
AT
вообще фича C++17, но про выстрелы в ногу гуглится 2006 года сообщения
AT
конечно, т.к. у тебя длл и ехе вместе не линкуются
почти очевидно, но может быть её ввели так, что происходит "weak экспорт" какой-нибудь?
АК
почти очевидно, но может быть её ввели так, что происходит "weak экспорт" какой-нибудь?
тут экспорт из дллки, а не из TU - совсем другое
AT
ну да. Есть ведь возможность данные экспортировать
DF
С weak export не будет нарушения odr?
AT
Dollar Føølish
С weak export не будет нарушения odr?
хз) я сам придумал, не знаю есть ли такой
DF
У эльфов есть weak, когда можно слинковать бинарник даже в отсутствие символа, за длл не хнаю
AT
я под dll понимаю и elf-овские so
AT
под weak мыслится такое, что если есть в импортируемом модуле символ с таким именем, то используется его адрес, иначе какой-то дефолтный
AT
в случае с функциями это реализуемо проставлением просто разных адресов для jmp, а с данными... ну разве что-то с виртуальной памятью мутить
DF
PLT секция патчится линкером в рантайме
DF
Там не просто подстановка адресов в jmp
DF
С данными реализуемо опять же через патчинг линкаж-секции
AT
ну вот. Значит все средства есть
AT
так что почему бы inline static не переживать нормально границы exe/dll
DF
Да,но мне кажется все равно нарушение одр будет