This isn't causing any functional problem today, but technically
`mapped[tls_offset..]` runs past the tls part of `mapped` and into
the `Instance` storage, and currently `prepareArea()` memsets its
entire argument to zero. It is only the current layout and
initialization order of `mapped` that prevents this from being a
problem. Being more precise here avoids future footguns if any of
that changes.
The main goal here is to make incremental compilation work a bit better.
I also slightly expanded some `std.zig.llvm.Builder` APIs so that we
don't need to pointlessly create new `Global`s whenever e.g. a function
turns into a variable or vice versa.
Also, lean into aliases for exports! If we just use aliases for every
export, everything becomes simpler. Besides, we can't just go around
renaming the globals of `Nav`s: the export could disappear on a future
update, in which case we'd have to somehow revert that change, which is
easier said than done.
Users can proceed by telling the build system how much memory to assume
the system has. I have improved the failure message to communicate this.
Partially reverts 87f8f47ba5
Even if we wanted to unrevert this reverted commit, it's not sufficient
to merely downgrade the failure to a warning, because the main
scheduling logic will fail to schedule steps that have a max_rss
exceeding the detected system value, causing some steps to never get
executed, eventually tripping an assert. Such a change would need to
also override the max_rss value to be equal to the greatest value across
all steps.
closes#31510
RFC 9110 says
> It is RECOMMENDED that all senders and recipients support, at a minimum,
> URIs with lengths of 8000 octets in protocol elements.
closes#30207
Previously, each message requires an unseekable error to be returned
from a syscall before proceeding. Ideally, the code would just pass
around `*std.Io.Writer` instead of `std.Io.File` in the first place, but
even then, you could argue for saving a syscall with `writerStreaming`.
This prevents a race between `alloc` and `free` where T1 receives memory
from `alloc` that is semantically about to be freed by T2 and still being
accessed, but the `free` is already visible to T1. Using acquire-release
here guarantees that any `free` is only published after all accesses to
the memory being freed have already happened.
Co-authored-by: Jacob Young <amazingjacob@gmail.com>
This prevents a race between `alloc` and `free` where T1 receives memory
from `alloc` that is semantically about to be freed by T2 and still being
accessed, but the `free` is already visible to T1. Using acquire-release
here guarantees that any `free` is only published after all accesses to
the memory being freed have already happened.
Co-authored-by: Jacob Young <amazingjacob@gmail.com>
This reverts commit 589bcb2544.
The scenario presented in the reverted commit cannot actually happen.
Even if there are two contiguous arena nodes N1 and N2 and the `end_index`
of N1 points to somewhere in N2, a `resize` can never lead to an increase
of the `end_index` of N1 since it checks whether it's `<= size` first.
A `resize`/`free` *can* decrease `end_index`, but even if it is wrongly
assumed that some allocation that belongs to N2 actually belongs to N1
based on the `end_index` of N1, it can only ever be decreased to the start
of the buffer of N2. That's because a valid allocation of N2 logically
cannot be at any lower address than N2 itself. And any point still in N2
can never also be in N1, so there's no danger of overwriting any other
allocations of N1.
Address two separate but related issues:
- Return value of `RtlQueryPerformanceFrequency` was used inconsistently; it
returns a nonzero value to indicate success.
- `timeoutToWindowsInterval` wasn't converting absolute deadlines back to the
Windows epoch before passing them to the system, which meant that values (in
the Unix epoch) were always in the distant past, so sleeps would return
immediately.
Fixes#31653
Some initial work towards https://codeberg.org/ziglang/zig/issues/31414.
Conclusion from this: Only x86-freebsd, x86-haiku, and x86-illumos remain time32
and are currently unfixable. I don't think the upstreams for any of these
targets actually care about them anymore (probably why they weren't migrated to
time64), so this is not a particularly big concern.
I split UTIME constants out from timespec because they were causing unreasonable
code duplication by being there.
I understand the temptation to exploit page size knowledge to make this function
faster, but I don't think this code can ever be compatible with any reasonable
set of pointer provenance/aliasing rules. At the very least, I don't believe it
is compatible with LLVM's.
closes https://github.com/ziglang/zig/issues/23184
It is now ignored for inputs from the corpus to ensure the filesystem
and process corpus stay in sync. For other (nondeterministic) inputs the
input builder is now reset.
The first issue is that when len(Sn) >= 128,
we perform Sn xor D instead of the Sn xorend D
that is specified in RFC 5297.
The second issue is that we truncate the Sn
if it is larger than 4096 bytes, which could
lead to collisions between inputs. We solve
this by absoring the Sn into the CMAC state
perform the last 16 bytes, xoring those 16
bytes with D as described in the first issue,
and then updating and squeezing the CMAC.
As established in 048e38624e and d70bd0b37e, mutexes should use a strong
cmpxchg when attempting to lock to guarantee that they actually succeed
if they aren't locked yet.
Also deletes an unused near-duplicate of `mutexLock()`.
The `cmpxchgWeak` in `setIpcFile` could lead to the IPC file not being set
even though there's still a slot available because one or more slots were
spuriously skipped.
The `cmpxcheWeak` in `serialize` could lead to an unused IPC slot not
being locked and used even though it could be.
Andrew Kelley