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.
Given that the previous design would require the use of a default
allocator to have `ArgIterator.init()` work in WASI, and since in
Zig we're trying to avoid default allocators, I've changed the design
slightly in that now `init()` is a compile error in WASI, and instead
in its message it points to `initWithAllocator(*mem.Allocator)`.
The latter by virtue of requiring an allocator as an argument can
safely be used in WASI as well as on other OSes (where the allocator
argument is simply unused). When using `initWithAllocator` it is then
natural to remember to call `deinit()` after being done with the
iterator. Also, to make use of this, I've also added `argsWithAllocator`
function which is equivalent to `args` minus the requirement of supplying
an allocator and being fallible.
Finally, I've also modified the WASI only test `process.ArgWasiIterator`
to test all OSes.
This commit pulls WASI specific implementation of args extraction
from the runtime from `process.argsAlloc` and `process.argsFree`
into a new iterator struct `process.ArgIteratorWasi`. It also
integrates the struct with platform-independent `process.ArgIterator`.
I'm not sure why I disabled them when landing extended Wasm/WASI
support, but they pass the parser tests just fine now, so I'm gonna
go ahead and re-enable them.
* change miscellaneous things to more idiomatic zig style
* change the digest length to 24 bytes instead of 48. This is
still 70 more bits than UUIDs. For an analysis of probability of
collisions, see:
https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions
* fix the API having the possibility of mismatched allocators
* fix some error paths to behave properly
* modify the guarantees about when file contents are loaded for input files
* pwrite instead of seek + write
* implement isProblematicTimestamp
* fix tests with regards to a working isProblematicTimestamp function.
this requires sleeping until the current timestamp becomes
unproblematic.
* introduce std.fs.File.INode, a cross platform type abstraction
so that cache hash implementation does not need to reach into std.os.
People using the API as intended would never trigger this assertion
anyway, but if someone has a non standard use case, I see no reason
to make the program panic.
If a user doesn't care that the manifest failed to be written, they can
simply ignore it. The program will still work; that particular cache
item will simply not be cached.
It checks whether the cache will respond correctly to inputs that don't
initially depend on filesystem state. In that case, we have to check
for the existence of a manifest file, instead of relying on reading the
list of entries to tell us if the cache is invalid.
Instead of releasing the manifest file when an error occurs, it is
only released when when `CacheHash.release` is called. This maps better
to what a zig user expects when they do `defer cache_hash.release()`.
A file handle is not the same thing as an inode index number.
Eventually the inode will be checked as well, but there needs to be
a way to get the inode in `std` first.