this removes the following configure options:
* ZIG_LIBC_LIB_DIR
* ZIG_LIBC_STATIC_LIB_DIR
* ZIG_LIBC_INCLUDE_DIR
* ZIG_DYNAMIC_LINKER
* ZIG_EACH_LIB_RPATH
* zig's reliance on CMAKE_INSTALL_PREFIX
these options are still available as command line options, however,
the default will attempt to execute the system's C compiler to
collect system defaults for these values.
closes#870
We now use a generic Rand structure which abstracts the core functions
from the backing engine.
The old Mersenne Twister engine is removed and replaced instead with
three alternatives:
- Pcg32
- Xoroshiro128+
- Isaac64
These should provide sufficient coverage for most purposes, including a
CSPRNG using Isaac64. Consumers of the library that do not care about
the actual engine implementation should use DefaultPrng and DefaultCsprng.
libxml2 is a required library, but we only find out that when the build
fails to link against it, if it is not present. The same for zlib.
We use find_library to find these two libraries and print nice fail
messages if they are not found.
Add basic address->symbol resolution support. Uses symtab data from the
MachO image, not external dSYM data; that's left as a future exercise.
The net effect is that we can now map addresses to function names but
not much more. File names and line number data will have to wait until
a future pull request.
Partially fixes#434.
* move std.io.File to std.os.File
* add `zig fmt` to self hosted compiler
* introduce std.io.BufferedAtomicFile API
* introduce std.os.AtomicFile API
* add `std.os.default_file_mode`
* change FileMode on posix from being a usize to a u32
* add std.os.File.mode to return mode of an open file
* std.os.copyFile copies the mode from the source file instead of
using the default file mode for the dest file
* move `std.os.line_sep` to `std.cstr.line_sep`
Add fallback paths for when the getrandom(2) system call is not
available. Try /dev/urandom first and sysctl(RANDOM_UUID) second.
The sysctl issues a warning in the system logs with some kernels but
that seems like an acceptable tradeoff for the fallback of a fallback.
These are on the slower side and could be improved. No performance optimizations
yet have been done.
```
Cpu: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
```
-- Sha3-256
```
Zig --release-fast
93 Mb/s
Zig --release-safe
99 Mb/s
Zig
4 Mb/s
```
-- Sha3-512
```
Zig --release-fast
49 Mb/s
Zig --release-safe
54 Mb/s
Zig
2 Mb/s
```
Interestingly, release-safe is producing slightly better code than
release-fast.
Some performance comparisons to C.
We take the fastest time measurement taken across multiple runs.
The block hashing functions use the same md5/sha1 methods.
```
Cpu: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
Gcc: 7.2.1 20171224
Clang: 5.0.1
Zig: 0.1.1.304f6f1d
```
See https://www.nayuki.io/page/fast-md5-hash-implementation-in-x86-assembly:
```
gcc -O2
661 Mb/s
clang -O2
490 Mb/s
zig --release-fast and zig --release-safe
570 Mb/s
zig
50 Mb/s
```
See https://www.nayuki.io/page/fast-sha1-hash-implementation-in-x86-assembly:
```
gcc -O2
588 Mb/s
clang -O2
563 Mb/s
zig --release-fast and zig --release-safe
610 Mb/s
zig
21 Mb/s
```
In short, zig provides pretty useful tools for writing this sort of
code. We are in the lead against clang (which uses the same LLVM
backend) with us being slower only against md5 with GCC.
Andrew Kelley
Marc Tiehuis
tgschultz
Wander Lairson Costa
Ben Noordhuis
David McFarland
Andrea Orru
Josh Wolfe