archive/zip: fail fast if UncompressedSize64 < nread
The zip reader checks that the uncompressed file size is valid
after all compressed files read until EOF.
However in between reading each file, there could have already
been an overflow where nread > UncompressedSize64 hence this
change will now return ErrFormat in such situations.
For various reasons Intel has suspended viewing web pages in the .ru
domain, so change the domain of the documents cited in the code
to the .com domain. In addition, the chapter numbers in the document
were updated and fix it.
Change-Id: I718be1548ec46f05ebc4f73873d4635c1d5fc76d
Reviewed-on: https://go-review.googlesource.com/c/go/+/399060
Reviewed-by: Ian Lance Taylor <email address hidden>
Run-TryBot: Ian Lance Taylor <email address hidden>
TryBot-Result: Gopher Robot <email address hidden>
Reviewed-by: Emmanuel Odeke <email address hidden>
Auto-Submit: Emmanuel Odeke <email address hidden>
db7183c...
by
Ian Lance Taylor <email address hidden>
go/build: remove unused fileInfo.embedErr field
Change-Id: If86a0402dae32c57d07545ee6d818010e0e4b5ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/399255
Trust: Ian Lance Taylor <email address hidden>
Run-TryBot: Ian Lance Taylor <email address hidden>
TryBot-Result: Gopher Robot <email address hidden>
Reviewed-by: Dmitri Shuralyov <email address hidden>
0f0c892...
by
"Paul E. Murphy" <email address hidden>
crypto/aes: merge ppc64le crypt key expansion
It is not necessary to expand the key twice for each direction,
the decrypt key can be stored in reverse simultaneously.
Likewise, there is no need to store the key length alongside the
expanded keys, this is now inferred by the key length slice.
Noteably, the key expansion benchmark assumes the key array size
is the exact size of the expanded key.
Now, the ppc64le aes asm interface is identical to the generic
asm interface. Callsites and usage is updated to reflect this.
Performance uplift on POWER9 is substantial:
name old time/op new time/op delta
Expand 167ns ± 0% 49ns ± 0% -70.55%
db576c9...
by
Johan Jansson <email address hidden>
net/textproto: initialize commonHeader in canonicalMIMEHeaderKey
Call initCommonHeader in canonicalMIMEHeaderKey to ensure that
commonHeader is initialized before use. Remove all other calls to
initCommonHeader, since commonHeader is only used in
canonicalMIMEHeaderKey.
This prevents a race condition: read of commonHeader before
commonHeader has been initialized.
Add regression test that triggers the race condition which can be
detected by the race detector.
3a19102...
by
"Bryan C. Mills" <email address hidden>
cmd/vendor: revert vendored code mistakenly modified in CL 398734
CL 398734 mistakenly modified
cmd/vendor/golang.org/x/arch/ppc64/ppc64asm/tables.go, which causes
the cmd/internal/moddeps to (correctly) fail due to modified vendored
code. This reverts the edit by re-running 'go mod vendor'.
cmd/go: cgo export header to be compatible with MSVC complex types
After CL 379474 has landed, the only remaining cgo export header
incompatibility with MSVC is the use of the _Complex macro,
which is not supported in MSVC even when it is part of the ISO C99
standard (1).
Since MSVC 2015 (2), complex math are supported via _Fcomplex and
_Dcomplex, which are equivalent to float _Complex and double _Complex.
As MSVC and C complex types have the same memory layout, we should
be able to typedef GoComplex64 and GoComplex128 to the appropriate
type in MSVC.
It is important to note that this CL is not adding MSVC support to cgo.
C compilers should still be GCC-compatible.
This CL is about allowing to include, without further modifications,
a DLL export header generated by cgo, normally using Mingw-W64 compiler,
into a MSVC project. This was already possible if the export header
changes introduced in this CL were done outside cgo, either manually or
in a post-build script.
