This reverts commit 8b10970836480a43a3bbb1276cb258c2a8b613f2.
This implementation has the following problems:
* It does not provide context to the less than function. This will be an
API break in order to fix.
* It uses recursion, causing unbounded stack memory usage - likely
depending on user input, which is extra problematic.
* Sorting linked lists is generally an inefficient operation;
encouraging it by having a standard library function for it may
lead to suboptimal software being written in Zig.
Furthermore, there is almost no benefit to providing a sort function as
a method, when a third party implementation can easily be passed a
linked list to then be sorted.
Also remove the TODO--it was added in fd067fbe8b14c445ed764da15fff5163156126df, but the current code no longer used that workaround, so this TODO didn't seem relevant anymore.
* move std.atomic.Atomic to std.atomic.Value
* fix incorrect argument order passed to testing.expectEqual
* make the functions be a thin wrapper over the atomic builtins and
stick to the naming conventions.
* remove pointless functions loadUnchecked and storeUnchecked. Instead,
name the field `raw` instead of `value` (which is redundant with the
type name).
* simplify the tests by not passing every possible combination. Many
cases were iterating over every possible combinations but then not
even using the for loop element value!
* remove the redundant compile errors which are already implemented by
the language itself.
* remove dead x86 inline assembly. this should be implemented in the
language if at all.
This was originally supposed to be a lock-free queue, but I gave up on
that and made it be a thread-safe queue instead.
Putting the mutex directly inside the queue data structure makes it
non-composeable. Instead, the recommendation is to use a normal queue
protected by an external mutex.
This was originally supposed to be a lock-free stack, but I gave up on
that and made it be a thread-safe stack which is implemented poorly
using spin locks. Nobody should use this data structure.
The alternative is a normal stack protected by a mutex.
* remove `std.atomic.Ordering`
- it is provided by the language with `std.builtin.AtomicOrder`.
* remove `std.atomic.fence`
- it is provided by the language with `@fence`.
* remove `std.atomic.compilerFence`
- if this is desired, it should be a language feature, not a standard
library function with inline asm.
This reverts commit da94227f783ec3c92859c4713b80a668f1183f96, reversing
changes made to 8f943b3d33432a26b7e242c1181e4220ed400501.
I was against this change originally, but decided to approve it to keep
an open mind. After a year of trying it in practice, I firmly believe
that the previous way of doing it was better.
* Take advantage of multi-object for loops.
* Remove use of BoundedArray since it had no meaningful impact on safety
or readability.
* Simplify some complex expressions, such as using `!` to invert a
boolean value.
We definitely want ArrayList in the standard library. Do we want
BoundedArray? Maybe, maybe not. But that makes ArrayList a more stable
dependency for std.fs.
This is useful when you want to have an array list backed by a fixed
slice of memory and no Allocator will be used.
It's an alternative to BoundedArray as you will see in the following
commit.
In general, I don't like the idea of std.meta.trait, and so I am
providing some guidance by deleting the entire namespace from the
standard library and compiler codebase.
My main criticism is that it's overcomplicated machinery that bloats
compile times and is ultimately unnecessary given the existence of Zig's
strong type system and reference traces.
Users who want this can create a third party package that provides this
functionality.
closes#18051
Justification: It is common for non-CPU bound short routines to do
non-blocking accept to eliminate unnecessary delays before subscribing
to data, for example in hardware integration tests.
```zig
const std = @import("std");
pub fn main() !void {
var addr: *u8 = @ptrFromInt(0xaaaaaaaaaaaaaaaa);
addr.* = 1;
}
```
On x86_64-linux:
Before:
```
$ zig run x.zig
Segmentation fault at address 0x0
/home/wooster/Desktop/zig/x.zig:5:5: 0x21d887 in main (x)
addr.* = 1;
^
/home/wooster/Desktop/zig-linux-x86_64/lib/std/start.zig:583:37: 0x21d847 in posixCallMainAndExit (x)
const result = root.main() catch |err| {
^
/home/wooster/Desktop/zig-linux-x86_64/lib/std/start.zig:251:5: 0x21d371 in _start (x)
asm volatile (switch (native_arch) {
^
???:?:?: 0x0 in ??? (???)
Aborted (core dumped)
```
After:
```
$ zig run x.zig --zig-lib-dir lib
General protection exception
/home/wooster/Desktop/zig/x.zig:5:5: 0x21d907 in main (x)
addr.* = 1;
^
/home/wooster/Desktop/zig/lib/std/start.zig:583:37: 0x21d8c7 in posixCallMainAndExit (x)
const result = root.main() catch |err| {
^
/home/wooster/Desktop/zig/lib/std/start.zig:251:5: 0x21d3f1 in _start (x)
asm volatile (switch (native_arch) {
^
???:?:?: 0x0 in ??? (???)
Aborted (core dumped)
```
As @IntegratedQuantum pointed out in <https://github.com/ziglang/zig/issues/17745#issuecomment-1783815386>,
it seems that if `code` of the `siginfo_t` instance is a certain value (128), you are able to distinguish between
a general protection exception and a segmentation fault.
This does not seem to be documented on `man sigaction`:
```
The following values can be placed in si_code for a SIGSEGV signal:
SEGV_MAPERR
Address not mapped to object.
SEGV_ACCERR
Invalid permissions for mapped object.
SEGV_BNDERR (since Linux 3.19)
Failed address bound checks.
SEGV_PKUERR (since Linux 4.6)
Access was denied by memory protection keys. See pkeys(7). The protection key which applied to this access is available via si_pkey.
```
(those constants are 1, 2, 3, and 4; none of them are the 128)
I can't find a lot of documentation about this but it seems to work consistently for me on x86_64-linux.
Here is a gist which provides additional evidence that this is a reliable way of checking for a general protection fault:
https://gist.github.com/ytoshima/5682393 (read comment in first line)
See also: https://stackoverflow.com/questions/64309366/why-is-the-segfault-address-null-when-accessing-memory-that-has-any-of-the-16-mo
This only seems to affect x86_64 and on 32-bit x86 this does not seem to be a problem.
Helps with #17745 but doesn't close it because the issue still exists on Windows and other POSIX OSs.
I also limited this to x86_64-linux for now because that's the only platform where I tested it. Might work on more POSIX OSs.
Instead of `zig init-lib` and `zig init-exe`, now there is only
`zig init`, which initializes any of the template files that do not
already exist, and makes a package that contains both an executable and
a static library. The idea is that the user can delete whatever they
don't want. In fact, I think even more things should be added to the
build.zig template.
Seems like this restriction was actual when Ziglang had extern enums,
but now it's not neccessary and can be lifted. It was present since
original PR which introduced std.enums, https://www.github.com/ziglang/zig/pull/8171.
See also: https://ziggit.dev/t/catching-invalid-enum-value-errors/2206/11
* Make `count` comptime_int instead of usize
With previous type, creating EnumIndexer for enum(usize) and enum(isize)
would cause compile error since `count` could not store maxInt(usize) + 1.
Now it can store it and reflects len field from std.builtin.Type.Array
(most common use case of count field inside std.enums functions is creating arrays).
Signed-off-by: Eric Joldasov <bratishkaerik@getgoogleoff.me>
