looking at `man getgroups` and `info getgroups` this is given as an
example:
```c
// Here's how to use ‘getgroups’ to read all the supplementary group
// IDs:
gid_t *
read_all_groups (void)
{
int ngroups = getgroups (0, NULL);
gid_t *groups
= (gid_t *) xmalloc (ngroups * sizeof (gid_t));
int val = getgroups (ngroups, groups);
if (val < 0)
{
free (groups);
return NULL;
}
return groups;
}
```
getgroups(0, NULL) is used to get the count of groups so that the
correct count can be used to allocate a list of gid_t. This small changes makes this
possible.
equivalent example in Zig after the change:
```zig
// get the group count
const ngroups: usize = std.os.linux.getgroups(0, null);
if (ngroups <= 0) {
return error.GetGroupsError;
}
std.debug.print("number of groups: {d}\n", .{ngroups});
const groups_gids: []u32 = try alloc.alloc(u32, ngroups);
// populate an array of gid_t
_ = std.os.linux.getgroups(ngroups, @ptrCast(groups_gids));
```
There's been some proliferation of dependency URLs that reference
mutable data such as links to git branches that can change. This has
resulted in broken projects, i.e.
* 9eef9de94c/build.zig.zon
* 4b64353e9c
There's also disagreement about whether it's fine for URL's to point to
git branches, i.e.
https://github.com/Not-Nik/raylib-zig/pull/130
This updates the docs to mention that zig won't be able to use URLs if
their content changes.
compiler: disallow `callconv` etc from depending on function parameters
Also, disallow `align`/`linksection`/`addrspace` annotations on container-level declarations with comptime-only types.
This includes function aliases, but not function declarations.
Also, re-introduce a target check for function alignment which was
inadvertently removed in the prior commit.
This commit amends `std.Build.ExecutableOptions` etc to have a new
field, `root_module`, which allows artifacts to be created whose root
module is an existing `*Module` rather than a freshly constructed one.
This API can be far more versatile, allowing construction of complex
module graphs before creating any compile steps, and therefore also
allowing easy reuse of modules.
The fields which correspond to module options, such as
`root_source_file`, are all considered deprecated. They may not be
populated at the same time as the `root_module` field. In the next
release cycle, these deprecated fields will be removed, and the
`root_module` field made non-optional.
At the expense of a slight special case in the build runner, we can make
the handling of dependencies between modules a little shorter and much
easier to follow.
When module and step graphs are being constructed during the "configure"
phase, we do not set up step dependencies triggered by modules. Instead,
after the configure phase, the build runner traverses the whole
step/module graph, starting from the root top-level steps, and
configures all step dependencies implied by modules. The "make" phase
then proceeds as normal. Also, the old `Module.dependencyIterator` logic
is replaced by two separate iterables. `Module.getGraph` takes the root
module of a compilation, and returns all modules in its graph; while
`Step.Compile.getCompileDependencies` takes a `*Step.Compile` and
returns all `*Step.Compile` it depends on, recursively, possibly
excluding dynamic libraries. The old `Module.dependencyIterator`
combined these two functions into one unintuitive iterator; they are now
separated, which in particular helps readability at the usage sites
which only need one or the other.
This commit changes the `root_module` field of `std.Build.Step.Compile`
to be a `*Module` rather than a `Module`. This is a breaking change, but
an incredibly minor one (the full potential extent of the breakage can
be seen in the modified standalone test).
This change will be necessary for an upcoming improvement, so it was
convenient to make it here.
(With the exception of x86 since that was available from the beginning.)
These were determined by analyzing the full, reconstructed Git history of the
Linux kernel here: https://landley.net/kdocs/fullhist
