Тёмная тема
Panzerschrek[CN]
> Похоже на ошибку компилятора.
Нет. Это не ошибка компилятора. Это (совершенно внезапно) ожидаемое поведение. Компилятор делает всё в соответствии со спецификацией микрософта. Просто спецификация микрософта считает, что конкретно вот в этом случае нужно отойти от стандарта и повредить стек.
pahaa
А что тут MS считает что надо делать не как все остальные?
=A=L=X=
> На мой взгляд это выход за пределы массива. Это грёбанный heap/stack
> corruption.
> Вот это - бич и бич осязаемый от которого очень трудно избавиться - потому что
> он непредсказуем, трудно определяется где происходит
А что мешает делать вот так:
typedef struct int_array { int *body; size_t count; } int_array_t; void array_print(int_array_t array) { size_t u; for ( u = 0; u < array.count; ++u) { ... } }
И прогонять тесты с -fsanitize=address,undefined ?
=A=L=X=
> Так вот wstring в винде - это 16-битные чары, а в линупсе - 32-битные. Именно
> поэтому чтобы различать ввели u16/u32.
> Ну и конечно я на это напоролся когда реализовывал сетевое взаимодействие между
> Window и Android.
> Несмотря на то что как трушный сишник использовал std::wstring. Ну и получил
> heap corrupt как нефиг делать.
> Благо быстро локализовал, т.к. побитые символы сразу бросались в глаза.
Это не у std::string проблемы, это на уровне проектирования просчёт. Есть понятие транспортной кодировки, которая должна быть всегда и везде utf8 и приниматься/передаваться, соответственно, только как std::string. То что там из Андроида торчит наружу utf16, - это тоже просчёт.
=A=L=X=
> std::wstring
> std::u16string
> std::u32string
Выпилить их нужно из стандарта, напрочь
=A=L=X=
В дельфи не было проблем, т.к. автоматически убиваемые типы там есть. Например строки. Как легко работать со строками в дельфи и какая боль с этим в Си. А все потому что, в том числе, не надо в явном виде ничего удалять и выделять.
Ну и соответственно идея автоматического управления памяти в том чтоб так легко было работать не только со строками. Ведь также можно работать и с массивами (складывать, фильтровать, хранить отфильтрованные слайсы в других объектах, ну и так далее), хешмапами, пользовательскими структурами данных. Вот мы и пришли к автоматическому управлению памятью. В дельфи оно ограничено определенными структурами (строками, динмассивами, интерфейсами), в С++ - также можно работать и с пользовательскими структурами данных.
Так что гц может и нет, но автоматическое управление нужно.
А дальше оказываются нужны слабые ссылки (потому что мы начали легко и просто работать с любыми структурами, а в этих структурах есть куча ссылок на owner\parent\enemy_target, т.е. вверх и вбок по иерархии). И эти ссылки должны гарантированно не протухать при удалении. Ну и на этом этапе видимо бизнес решает что гц сделать проще и надежнее, как еще объяснить что практически все современные языки с гц вместо автоподсчета ссылок.
Panzerschrek[CN]
> Там, где я обкладываюсь санитайзерами, Жабисты гоняют тесты.
жабисты не гоняют тесты для поиска мемори корапшен, их там нету никак
жабисты гоняют тесты для другого
pahaa
> Нет. Это не ошибка компилятора. Это (совершенно внезапно) ожидаемое поведение.
Я ничего не понял. Поясни поподробнее, что там проихсодит, что ожидается и где компилятор лажает.
0iStalker
> > std::wstring
> > std::u16string
> > std::u32string
>
> Выпилить их нужно из стандарта, напрочь
wstring - точно выпилить. Как и недоразумение wchar_t. А вот чисто u16/u32 для каких-то целей можно оставить.
exchg
> А что мешает делать вот так
останется еще выпилить memcpy, memset, и прочие функции работающие с указателями из стандартной библиотеки. Ну и из всех внешних библиотек тоже.
А тесты вполне могут иметь не 100%-е покрытие, так что это не спасет от редких граничных случаев которыми обязательно воспользуется хакер.
kipar
> останется еще выпилить memcpy, memset, и прочие функции работающие с
> указателями из стандартной библиотеки. Ну и из всех внешних библиотек тоже.
Удивительно, проблемой языка частью идеологию которого является расширение через библиотеки, являются библиотеки. Может в таком случае это проблема библиотек, а не языка?
С другой стороны, а кто мешает написать свою "расово верную библиотеку" и не брать плохие вешние библиотеки? Или брать только хорошие? Стандартных билиотек для тех же С, заточенных под свою специфику много разных.
> А тесты вполне могут иметь не 100%-е покрытие, так что это не спасет от редких
> граничных случаев которыми обязательно воспользуется хакер.
Могут и бывают, линкуй санитайзер в релиз. Используй gcov и длеай покрытие 100%. Пиши свою / бери чужую библиотеку с гард зонами. Тут нет универсального решения.
0iStalker
>Есть понятие транспортной кодировки, которая должна быть всегда и везде utf8
Кому и зачем должна?
Panzerschrek[CN]
>А вот чисто u16/u32 для каких-то целей можно оставить.
Нафиг не нужно, есть std::uint16_t, std::uint32_t, правда печально, что они не сильно std.
exchg
> Могут и бывают, линкуй санитайзер в релиз. Пиши свою / бери чужую библиотеку с
> гард зонами. Тут нет универсального решения.
так в этом и проблема и об этом говорит ALX. Универсальное решение есть в других языках, а в Си его нет.
kipar
> Как легко работать со строками в дельфи и какая боль с этим в Си.
Это - от ниосиляторства.
Конечно, если ставить вопрос о "строках вообще", на все случаи жизни, то, да в C все плохо. Но в каждом конкретном случае получается гораздо изящнее, чем с применением "тяжелой строковой артиллерии". Так, например, когда-то я для тренировки в Perl писал на нем интерпретатор Trac. Казалось бы, мощнейший аппарат регулярных выражений, заложенный в Perl, для задачи интерпретации строк - самое оно, но нет, оказалось все свелось к гораздо более простым операциям, но, зато, формат хранения строк перестал быть строковым.
Проблема только в том, что "современные программисты" не умеют вычислять символы (тяжелое наследие FORTRAN).
kipar
> Универсальное решение есть в других языках
И именно поэтому те языки не используют там где С/С++. А он говорит вот это:
=A=L=X=
> Только тем, что невозможно накосячить с heap corrupt и тебе в любом случае
> будет выкинуто исключение null pointer или index out of bounds и ты точно
> увидишь где проблема и в чём она сразу же по месту её возникновения. Только
> этим.
В Си/С++ это решается библиотеками. Т.е. тут его нету не столько потому, что его принципиально невозможно сделать, сколько тем что это не очень хорошее решение само по себе.
nes
> Кому и зачем должна?
У нормальных разработчиков должна быть в архитектуре.