# breaking changes to std.mem.Allocator interface API · gitcafe/zig

[View on GitCafe](https://git.cafe/gitcafe/zig/commit/9c13e9b7ed9806d0f9774433d5e24359aff1b238)

Repository: [gitcafe/zig](https://git.cafe/gitcafe/zig)

Visibility: public

Requested revision: 9c13e9b7ed9806d0f9774433d5e24359aff1b238

Requested commit: 9c13e9b7ed9806d0f9774433d5e24359aff1b238

Commit: 9c13e9b7ed9806d0f9774433d5e24359aff1b238

Tree: 5e595fd2182648e660db56b88b86f162810df8f4

Author: Andrew Kelley

Committer: Andrew Kelley

## Message

```
breaking changes to std.mem.Allocator interface API

Before, allocator implementations had to provide `allocFn`,
`reallocFn`, and `freeFn`.

Now, they must provide only `reallocFn` and `shrinkFn`.
Reallocating from a zero length slice is allocation, and
shrinking to a zero length slice is freeing.

When the new memory size is less than or equal to the
previous allocation size, `reallocFn` now has the option
to return `error.OutOfMemory` to indicate that the allocator
would not be able to take advantage of the new size.

For more details see #1306. This commit closes #1306.

This commit paves the way to solving #2009.

This commit also introduces a memory leak to all coroutines.
There is an issue where a coroutine calls the function and it
frees its own stack frame, but then the return value of `shrinkFn`
is a slice, which is implemented as an sret struct. Writing to
the return pointer causes invalid memory write. We could work
around it by having a global helper function which has a void
return type and calling that instead. But instead this hack will
suffice until I rework coroutines to be non-allocating. Basically
coroutines are not supported right now until they are reworked as
in #1194.

```

## Parents

- [4090fe81f600afa290de5bf06a287d5fab2ea9dc](https://git.cafe/gitcafe/zig/commit/4090fe81f600afa290de5bf06a287d5fab2ea9dc?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zig/tree/9c13e9b7ed9806d0f9774433d5e24359aff1b238?format=markdown)