...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.
* 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)
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 b8ce8f219c.
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.
If fmt was called on with a [*]u8 or [*]const u8 argument, but the fmt string did not specify 's' to treat it as a string, it produced a compile error due to accessing index 1 of a 0 length slice.
Distro's llvm usually have a 6.0 suffix.Any custom llvm build
names the binary as llvm-config.Keeping 6.0 variant first causes
the distro's llvm to be compiled in place of a custom one even if
given using CMAKE_PREFIX_PATH.
Andrew Kelley
Marc Tiehuis
Shawn Landden
kristopher tate
Raul Leal
Michael Noronha
tgschultz
prazzb