История изменений
Исправление Iron_Bug, (текущая версия) :
ну так косяки в софте - не проблема musl. понятно, что с кривыми руками к нему лучше не приближаться. там, где glibc понаделает всяких подушек и заглушек, musl просто честно выполнит инструкцию. если программист написал фигню - фигня и выполнится. и поэтому, без всяких проверок на каждый чих, он работает быстрее.
конкретно про распределение памяти - это зависит от кучи параметров. от компилятора (причём повторяемые компиляции - это ещё отдельная сложная тема), от библиотек, от реализации выделения памяти, от архитектуры процессора. так что то, что при ошибках не падало две недели, потом вдруг может упасть сразу, или вообще не упасть, или упасть только при выполнении на нескольких ядрах, или только на одном. но память-то портится. и это просто баги софта. но для отладки, внезапно, не нужно, чтобы софт прямо шлёпнулся с явным сегфолтом. для этого есть другие средства. тот же valgrind прекрасно справляется. и не надо никакой попсы. есть средства отладки в сложных условиях, на серверах, когда ошибка может вылезать раз в полгода. я не буду углубляться. но по хорошему, просто надо писать код с умом. тогда и такая отладка не понадобится.
musl реализует стандарт. всё остальное - на разработчике.
Исправление Iron_Bug, :
ну так косяки в софте - не проблема musl. понятно, что с кривыми руками к нему лучше не приближаться. там, где glibc понаделает всяких подушек и заглушек, musl просто честно выполнит инструкцию. если программист написал фигню - фигня и выполнится. и поэтому, без всяких проверок на каждый чих, он работает быстрее.
конкретно про распределение памяти - это зависит от кучи параметров. от компилятора (причём повторяемые компиляции - это ещё отдельная сложная тема), от библиотек, от реализации выделения памяти, от архитектуры процессора. так что то, что при ошибках не падало две недели, потом вдруг может упасть сразу, или вообще не упасть, или упасть только при выполнении на нескольких ядрах, или только на одном. но память-то портится. и это просто баги софта. но для отладки, внезапно, не нужно, чтобы софт прямо шлёпнулся с явным сегфолтом. для этого есть другие средства. тот же valgrind прекрасно справляется. и не надо никакой попсы. но по хорошему, просто надо писать код с умом. тогда и такая отладка не понадобится.
musl реализует стандарт. всё остальное - на разработчике.
Исправление Iron_Bug, :
ну так косяки в софте - не проблема musl. понятно, что с кривыми руками к нему лучше не приближаться. там, где glibc понаделает всяких подушек и заглушек, musl просто честно выполнит инструкцию. если программист написал фигню - фигня и выполнится. и поэтому, без всяких проверок на каждый чих, он работает быстрее.
конкретно про распределение памяти - это зависит от кучи параметров. от компилятора (причём повторяемые компиляции - это ещё отдельная сложная тема), от библиотек, от реализации выделения памяти, от архитектуры процессора. так что то, что при ошибках не падало две недели, потом вдруг может упасть сразу, или вообще не упасть, или упасть только при выполнении на нескольких ядрах, или только на одном. но память-то портится. и это просто баги софта.
musl реализует стандарт. всё остальное - на разработчике.
Исправление Iron_Bug, :
ну так косяки в софте - не проблема musl. понятно, что с кривыми руками к нему лучше не приближаться. там, где glibc понаделает всяких подушек и заглушек, musl просто честно выполнит инструкцию. если программист написал фигню - фигня и выполнится. и поэтому, без всяких проверок на каждый чих, он работает быстрее.
musl реализует стандарт. всё остальное - на разработчике.
Исходная версия Iron_Bug, :
ну так косяки в софте - не проблема musl. понятно, что с кривыми руками к нему лучше не приближаться. там, где glibc понаделает всяких подушек и заглушек, musl просто честно выполнит инструкцию. если программист написал фигню - фигня и выполнится. и поэтому, без всяких проверок на каждый чих, он работает быстрее.