Ran into this when using a program that uses CreateFileMapping and then trying to call `std.fs.createFile` on the mapped file. More info can be found here:
https://stackoverflow.com/questions/41844842/when-error-1224-error-user-mapped-file-occurs
Before:
```
error.Unexpected NTSTATUS=0xc0000243
C:\Users\Ryan\Programming\Zig\zig\lib\std\os\windows.zig:138:40: 0x7ff74e957466 in OpenFile (test.exe.obj)
else => return unexpectedStatus(rc),
^
```
After:
```
FAIL (AccessDenied)
C:\Users\Ryan\Programming\Zig\zig\lib\std\os\windows.zig:137:30: 0x7ff7f5b776ea in OpenFile (test.exe.obj)
.USER_MAPPED_FILE => return error.AccessDenied,
^
```
Returning a bool allows to conveniently use it as the condition
of a while loop.
Also remove restriction that ST cannot be double-word.
While imm is only 32-bit, this value is extended into a 64-bit
memory location.
Test coverage was lacking for chdir() on WASI, allowing this to
regress.
This change makes os.chdir() compile again, and improves the test
logic to use our standard CWD support for WASI.
perf_event_attr.type needs to take a runtime defined value to enable
dynamic PMU:s, such as kprobe and uprobe. This value can exceed
predefined values defined in the linux headers.
reference: perf_event_open(2) man page
* Export invalidFmtErr
To allow consistent use of "invalid format string" compile error
response for badly formatted format strings.
See https://github.com/ziglang/zig/pull/13489#issuecomment-1311759340.
* Replace format compile errors with invalidFmtErr
- Provides more consistent compile errors.
- Gives user info about the type of the badly formated value.
* Rename invalidFmtErr as invalidFmtError
For consistency. Zig seems to use “Error” more often than “Err”.
* std: add invalid format string checks to remaining custom formatters
* pass reference-trace to comp when building build file; fix checkobjectstep
- the meaning of packed structs changed in zig 0.10. adjust accordingly.
Use "extern struct" for the cases that directly map to C structs.
- Add new type info kinds, like enum64 and DeclTag
- change the Type enum to use the canonical names from libbpf.
This is more predictable when comparing with external BPF
documentation (than invented synonyms that need to be guessed)
* std.os.uefi: integer backed structs, add tests to catch regressions
device_path_protocol now uses extern structs with align(1) fields because
the transition to integer backed packed struct broke alignment
added comptime asserts that device_path_protocol structs do not violate
alignment and size specifications
This makes possible to query the memory map size from EFI firmware
without making any allocation beforehand. This makes possible to be
precise about the size of the allocation which will own a copy of
the memory map from the UEFI application.
- For ALU operations, src should be allowed to be an explicit Reg.
- Expose AluOp and JmpOp as public types.
This makes code generation using BPF as a backend easier,
as AluOp and JmpOp can be used directly as part of an IR
The definition of HKEY__ as a struct with an unused int field is only the case in the Windows headers when `STRICT` is defined. From https://learn.microsoft.com/en-us/windows/win32/winprog/enabling-strict:
> When STRICT is defined, data type definitions change as follows:
>
> - Specific handle types are defined to be mutually exclusive; for example, you will not be able to pass an HWND where an HDC type argument is required. Without STRICT, all handles are defined as HANDLE, so the compiler does not prevent you from using one type of handle where another type is expected.
Zig's `opaque {}` already gives this benefit to us, so the usage of a struct with an unused field is unnecessary, and it was causing HKEY to have an alignment of 4, which is a problem because there are HKEY constants like HKEY_LOCAL_MACHINE (0x80000002) that are not 4-byte aligned. Without this change, the compiler would not allow something like HKEY_LOCAL_MACHINE to be defined since it enforces pointer alignment.
This implements the new addition to the API: `sock_accept`.
Reference commit of WASI spec:
0ba0c5e2e37625ca5a6d3e4255a998dfaa3efc52
For full details:
0ba0c5e2e3
For entire spec at this commit:
0ba0c5e2e3/phases/snapshot/docs.md