[pjmlp]

That is the usual fallacy, because it assumes everyone has full access to whole source code and is tracking down all the places where heap is being used.

It also assumes that the OS doesn't lie to the application when allocations fail.

[simjnd]

Zig make allocations extremely explicit (even more than C) by having you pass around the allocator to every function that allocates to the heap. Even third-party libraries will only use the allocator you provide them. It's not a fallacy, you're in total control.

[dmytrish]

> pass around the allocator to every function that allocates to the heap.

what prevents a library from taking an allocator, saving it hidden somewhere and using it silently?

[simjnd]

Nothing, but it would be bad design (unless there is a legitimate documented reason for it). Then it's up to you as the developer to exercise your judgment and choose what third-party libraries you choose to depend on.

[ulbu]

authors of the library

[pjmlp]

Why, are you going to abort if too many calls to the allocator take place?

[simjnd]

You can if you want. You can write your own allocator that never actually touches the heap and just distributes memory from a big chunk on the stack if you want to. The point is you have fine grained (per function) control over the allocation strategy not only in your codebase but also your dependencies.

[pjmlp]

Allocation strategy isn't the same as knowing exactly exactly when allocations take place.

You missed the point that libraries can have their own allocators and don't expose customisation points.

[ulbu]

sure they can. but why would they choose to?

[pjmlp]

Because the language doesn't prevent them, and they own their library.

[renehsz]

> It also assumes that the OS doesn't lie to the application when allocations fail.

Gotta do the good ol'

  echo 2 >/proc/sys/vm/overcommit_memory

and maybe adjust overcommit_ratio as well to make sure the memory you allocated is actually available.

[pjmlp]

OS specific hack and unrelated to C.

[tredre3]

Your comment was also OS-specific because Windows doesn't lie to applications about failed allocations.

[pjmlp]

Not at all, rather there is no guarantee that the C abstract machine described on ISO C, actually returns NULL on memory allocation failures as some C advocates without ISO C legalese expertise seem to advocate.