Caused by struct printing behavior. Enums are different enough from structs and unions that the field iteration behavior doesn't do what we want even if @memberName didn't error on enums.
...rather than trying to find the executable on the file system.
Also use a more robust PIE offset calculation based on the
available metadata.
And for the last function, use the data that tells the end
rather than assuming 4K.
Also they print in a consistent way with Linux stack traces.
This does a proof of concept of changing most file system APIs to not
require an allocator and remove the possibility of failure via
OutOfMemory.
This also does most of the work of #534.
This reverts commit 937b822fa90181bf59f1c2ac45faab09342a183f, reversing
changes made to dd4b13ac0326aeb6c2c197bfac49f9e931ccee37.
Tests failing on Windows.
Re-opens #1360
* error.BadFd is not a valid error code. it would always be a bug to
get this error code.
* merge error.Io with existing error.InputOutput
* merge error.PathNotFound with existing error.FileNotFound.
Not all OS's support both.
* add os.File.openReadC
* add error.BadPathName for windows file operations with invalid
characters
* add os.toPosixPath to help stack allocate a null terminating byte
* add some TODOs for other functions to investigate removing the
allocator requirement
* optimize some implementations to use the alternate functions when
a null byte is already available
* add a missing error.SkipZigTest
* os.selfExePath uses a non-allocating API
* os.selfExeDirPath uses a non-allocating API
* os.path.real uses a non-allocating API
* add os.path.realAlloc and os.path.realC
* convert many windows syscalls to use the W versions (See #534)
This reintroduces b8ce8f219c48ae833199130ce575241f848d690b.
(reverting dd4b13ac0326aeb6c2c197bfac49f9e931ccee37)
Now with correct author information. Apologies to kristopher tate
and Michael Noronha.
ACHTUNG: llvm::APSInt stores an int's sign inside of its getRawData; Internally to Zig we store an integer's sign outside of getRawData! (~aps_int) calls .flip() internally on the raw data to match Zig.
test/translate_c.zig: enum: add wider range of values (u64) to try;
This reverts commit b8ce8f219c48ae833199130ce575241f848d690b.
Squashing the commits from the pull request resulted in kristopher tate
from being omitted from the authors. A future commit will merge
the code correctly.
* translate-c: Correctly translate enum init values
* translate-c: Test enum initialization
* translate-c: Flip to positive using APSInt builtins
* src/translate_c.cpp: correctly bridge llvm::APSInt with Zig BigInt;
ACHTUNG: llvm::APSInt stores an int's sign inside of its getRawData; Internally to Zig we store an integer's sign outside of getRawData! (~aps_int) calls .flip() internally on the raw data to match Zig.
* test/translate_c.zig: enum: add wider range of values (u64) to try;
closes#1360
This is identical to `mem.set(u8, slice, 0)` except that it will never
be optimized out by the compiler. Intended usage is for clearing
secret data.
The resulting assembly has been manually verified in --release-* modes.
It would be valuable to test the 'never be optimized out' claim in tests
but this is harder than initially expected due to how much Zig appears
to know locally. May be doable with @intToPtr, @ptrToInt to get around
known data dependencies but I could not work it out right now.
