AF
попробуй в васм этот код скомпилить
Size: a a a
2019 April 01
AF
проверишь заодно )
MV
вот тут ребята уже проверили :)
MV
как раз проблема в этом ub
AF
хах, с этого и начинать надо было )
AB
не ну я конечно могу написать несколько страниц а4 по этому поводу и сюда скидывать, но разве такого уровня детализации недостаточно, чтобы обсудить эту тему?
с не котрых пор malloc и wasm святы для меня его нельзя по трогать без даказательств.
MV
хах, с этого и начинать надо было )
ну там не только в этом косяк был, но последний, который я долго искал, был в этом ub
AF
issue тогда писать надо
AF
явный баг
NK
с не котрых пор malloc и wasm святы для меня его нельзя по трогать без даказательств.
Это никак не связано с wasm
MV
issue тогда писать надо
в самом musl нет багов, баг в PR, я им как раз сейчас в conversation всё распишу с ссылкой на работающую версию
AB
ID:414983998
Это никак не связано с wasm
не понел ?
NK
Ну это как винить, что x86 конвертирует float -> int по одному, а ARM по-другому (с насыщением если выходит за допустимые пределы). Это все зависит от компилятора. JS VM например не имеет таких проблем и ковертирует примерно так: (uint32_t)(fltVal % 4294967295) под капотом
NK
В C++ эта конвертация как раз UB, если fltVal > 4294967295.0
MV
а в mvp wasm - trap в trunc (partial operator), если выходит за пределы
NK
Да, в wasm mvp - трап, если не указывать специальные флаги, которые это полифилят и приводят к поведению C++
MV
в wasm многое из того, что в C/C++ UB, приводит к trap
AF
в wasm многое из того, что в C/C++ UB, приводит к trap
(по-умолчанию)