Иначе упадёт вм

С другой стороны, как можно в C сделать read-only я понять не могу

Т.е. если у меня есть просто реф на кусок памяти, то в С я могу менять внутри и все. Все их must нифига не стоят

Надо попробовать самому захуячить что-нибудь. Поломать иммутабельность

Потому что ничего не понятно.

Клонировать на каждом вызове функции кусок хипа должно быть медленно. Нужно ли это делать - а хз. Самое главное, что может и клонировать не сильно медленно ;)

тот ErlNifBinary, который получил из  erlang - нельзя мутировать, тот который слепил сам в Си - можно, но потом его надо перекинуть в erlang-term, который уже иммутабельный

Так а кто мне мешает мутировать Эрланговский?

С же не может помешать

Разыменовал укзатель, засунул новое значение. Конец

Или Beam в конце проверяет всю собственную память на изменения?

Хватит глумиться над вм.

Зачем, в конце концов?

Отдавайте референсы на свою память, в конце концов

Должны быть какие-то финализаторы для них

уже точно не помню, но помоему VM упадет с ошибкой: segmentation fault : 11

The use of resource objects is a safe way to return pointers to native data structures from a NIF. A resource object is only a block of memory allocated with enif_alloc_resource. A handle ("safe pointer") to this memory block can then be returned to Erlang by the use of enif_make_resource. The term returned by enif_make_resource is opaque in nature. It can be stored and passed between processes, but the only real end usage is to pass it back as an argument to a NIF. The NIF can then call enif_get_resource and get back a pointer to the memory block, which is guaranteed to still be valid. A resource object is not deallocated until the last handle term is garbage collected by the VM and the resource is released with enif_release_resource (not necessarily in that order).

А что будет, если двое параллельно дёрнут ниф?

а все тоже самое что и в обычном СИ

Жопа крч...