The high level Allocator interface API functions will now do a
`@returnAddress()` so that stack traces captured by allocator
implementations have a return address that does not include the
Allocator overhead functions. This makes `4` a more reasonable default
for how many stack frames to capture.
`std.GeneralPurposeAllocator` is now available. It is a function that
takes a configuration struct (with default field values) and returns an
allocator. There is a detailed description of this allocator in the
doc comments at the top of the new file.
The main feature of this allocator is that it is *safe*. It
prevents double-free, use-after-free, and detects leaks.
Some deprecation compile errors are removed.
The Allocator interface gains `old_align` as a new parameter to
`resizeFn`. This is useful to quickly look up allocations.
`std.heap.page_allocator` is improved to use mmap address hints to avoid
obtaining the same virtual address pages when unmapping and mapping
pages. The new general purpose allocator uses the page allocator as its
backing allocator by default.
`std.testing.allocator` is replaced with usage of this new allocator,
which does leak checking, and so the LeakCheckAllocator is retired.
stage1 is improved so that the `@typeInfo` of a pointer has a lazy value
for the alignment of the child type, to avoid false dependency loops
when dealing with pointers to async function frames.
The `std.mem.Allocator` interface is refactored to be in its own file.
`std.Mutex` now exposes the dummy mutex with `std.Mutex.Dummy`.
This allocator is great for debug mode, however it needs some work to
have better performance in release modes. The next step will be setting
up a series of tests in ziglang/gotta-go-fast and then making
improvements to the implementation.
* Added `replace` for simple pre-allocated search-and-replace
* Added `replacementSize` for calculating ahead-of-time buffer sizes for
performing a safe search-and-replace
* Added `replaceOwned` for automatically allocating and performing
replacement
When using C libraries, C99 designator list initialization is often
times used to initialize data structure.
While `std.mem.zeroes` and manually assigning to each field can
achieve the same result, it is much more verbose then the equivalent
C code:
```zig
usingnamespace @cImport({
@cInclude("sokol_app.h");
});
// Using `std.mem.zeroes` and manual assignment.
var app_desc = std.mem.zeroes(sapp_desc);
app_desc.init_cb = init;
app_desc.frame_cb = frame;
app_desc.cleanup_cb = cleanup;
app_desc.width = 400;
app_desc.height = 300;
app_desc.window_name = "no default init";
// Using `std.mem.defaultInit`.
var app_desc = std.mem.defaultInit(sapp_desc, .{
.init_cb = init,
.frame_cb = frame,
.cleanup_cb = cleanup,
.width = 400,
.height = 300,
.window_name = "default init"
});
```
The `std.mem.defaultInit` aims to solve this problem by zero
initializing all fields of the given struct to their zero, or default
value if any. Each field mentionned in the `init` variable is then
assigned to the corresponding field in the struct.
If a field is a struct, and an initializer for it is present, it is
recursively initialized.
Jonathan S writes:
On common systems with a 022 umask, this will still result in a
file created with 755 permissions, but it works appropriately if the
system is configured more leniently. (As another data point, C's fopen
seems to open files with the 666 mode.)
