This is sadly very badly worded.

Zig provides a global allocator when running tests that will check for memory leaks and double frees. This allocator is only available in the test suite tho, if you want to compile an executable, one has to chose between several allocators and instantiate them explicitly.

There are three allocators that are globally available in the standard library: - `std.heap.c_allocator`, a wrapper around malloc/free. only available when linking libc - `std.heap.page_allocator`, a wrapper around VirtualAlloc/mmap. Can only allocate in OS page size granularity and is quite slow. A good backing for other allocators tho. - `std.testing.failing_allocator`, an allocator that will always yield OutOfMemory.

For the use in an application, there's the std.heap.GeneralPurposeAllocator type that needs to be explicitly instantiated, and it provides a good portion of debugging features right now. High-speed implementations are planned for release modes

There is no hidden implicit allocator used by the language or stdlib (like in Rust or C++), instead every stdlib API that allocates requires an allocator either in an initialization function, or as argument on individual functions.

The stdlib then provides a variety of allocator implementations that can be plugged into those allocator arguments.

To add to that, it's also idiomatic for external libraries in Zig to take an allocator as arguments, rather than using the libc's malloc like a lot of C libraries do.

Which as an aside, is a lovely feature when you’re doing things like working with external SPI PSRAM and rightfully want to treat it differently to your local SRAM in embedded applications.

We didn’t use Zig for our firmware, but we did come up with a similar approach in Nim (basically a neat type that takes allocators/frees/reallocs and handles managing the ref count so you can use the variable as any other Nim variable. It’s not perfect, but close enough for our purposes)

You left out a whole paragraph of context to the second statement, and especially chose to cut off even the beginning and end of that sentence:

> By convention, Zig has a global allocator that you’re encouraged to use for all your unit tests

If you read sentences in bits and pieces by themselves, you'll find that it does lead to a lot of misinterpretation.

I suspect this means that the Zig stdlib does not use a default allocator but Zig provides a default allocator that you have to intentionnally use in your functions if you want to allocate. Is this correct ?

This is correct, with the caveat that I believe zig provides several different allocators that you can pick and choose for various situations.

so the word 'default' may not necessarily apply the way it doesn't apply wrt to 'default pointer' in C++ because it offers both unique_ptr and shared_ptr with very different behaviors and semantics.

Came to point this out... I don't think I trust these people to write my compiler.