- flatten std.crypto.hash.Sha1 and give it a writable interface that
optimizes splats
- flatten std.hash.crc and give it a writable interface that optimizes
splats
- remove old writer impls from std.crypto
- add fs.File.Writer.moveToReader
- add fs.File.Writer.seekTo
- add std.io.Reader.Hashed and std.io.Writer.Hashed which are
passthrough streams. Instead of passing through to null writer, use
the writable interface implemented directly on hashers which doesn't
have to account for passing through the data.
- add std.io.BufferedWriter.writeSplatAll
- use ArrayList strategically to reduce allocations
- use a BufferedReader to avoid unnecessary memcpy of the certs
- use for loops
- skip certs with invalid magic instead of asserting
and rename std.io.BufferedWriter.writableSlice to writableSliceGreedy
and make writableSlice and writableArray advance the buffer end position
introduce std.io.BufferedWriter.writeSplatLimit but it's unimplemented
remove std.fs.Dir.readFileAllocOptions, replace with more flexible API
readFileIntoArrayList
remove std.fs.File.readToEndAllocOptions, replace with more flexible API
readIntoArrayList
update std.fs.File to new reader/writer API
add helper functions to std.io.Reader.Limit
replace std.io.Writer.FileLen with std.io.Reader.Limit
make offset a type rather than u64 so that it can distinguish between
streaming read and positional read
avoid an unnecessary allocation in std.zig.readSourceFileToEndAlloc when
there is a UTF-16 little endian BOM.
fix splat implementation in std.fs.File
update http.Client, with caveats:
* TODO: only 1 underlying write call
* TODO: don't rely on max_buffers_len exceeding the caller
* TODO: handle splat
update net.Stream API. also make it use WSASend on windows
On Linux, File.metadata calls the statx syscall directly. As such, the
return value is the error code. Previously, it handled the error with
`posix.errno`, which when libc is linked, treats the return value as a
value set to -1 if there is an error with the error code in errno. If
libc wasn't linked, it would be handled correctly.
In the Linux with libc linked case, this would cause the error result to
always be treated as success (err val != -1), even when an error
occurred.