[]byte("string") was simplifying to
[]byte{0: 0x73, 1: 0x74, 2: 0x72, 3: 0x69, 4: 0x6e, 5: 0x67},
but that latter form takes up much more memory in the compiler.
Preserve the string form and recognize it to turn global variables
initialized this way into linker-initialized data.
Reduces the compiler memory footprint for a large []byte initialized
this way from approximately 10 kB/B to under 100 B/B.
See also issue 6643.
R=golang-codereviews, r, iant, oleku.konko, dave, gobot, bradfitz
CC=golang-codereviews
https://golang.org/cl/15930045
Usually when a message is signed it's first hashed because RSA has low
limits on the size of messages that it can sign. However, some
protocols sign short messages directly. This isn't a great idea because
the messages that can be signed suddenly depend on the size of the RSA
key, but several people on golang-nuts have requested support for
this and it's very easy to do.
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/44400043
ZIP64 Extra records are variably sized, but we weren't capping
our reading of the extra fields at its previously-declared
size.
No test because I don't know how to easily create such files
and don't feel like manually construction one. But all
existing tests pass, and this is "obviously correct" (queue
laughter).
Fixes#7069
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/48150043
Adds tests for branches handling call ordering which
were shown to be untested by the cover tool.
This is part of the refactoring of form parsing discussed
in CL 44040043. These tests may need to be changed later but
should help lock in the current behaviour.
R=golang-codereviews, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/46750043
The Domain and Path field of a parsed cookie have been
the unprocessed wire data since Go 1.0; this seems to
be okay for most applications so let's keep it.
Returning the unprocessed wire data makes it easy to
handle nonstandard or even broken clients without
consulting Raw or Unparsed of a cookie.
The RFC 6265 parsing rules for domain and path are
currently buried in net/http/cookiejar but could be
exposed in net/http if necessary.
R=bradfitz, nigeltao
CC=golang-codereviews
https://golang.org/cl/48060043
Document what values a PublicSuffixList must accept as
a domain in a call to PublicSuffix.
R=bradfitz, nigeltao
CC=golang-codereviews
https://golang.org/cl/47560044
Require at least one space after "type" and do not fontify closing
parenthesis of type switch as a type.
R=adonovan
CC=golang-codereviews
https://golang.org/cl/37720050
Use copy rather than a hand rolled loop when moving a partial input
block to the scratch area. This results in a reasonable performance
gain when partial blocks are written.
Benchmarks on Intel(R) Xeon(R) CPU X5650 @ 2.67GHz with Go amd64:
benchmark old MB/s new MB/s speedup
SHA1 BenchmarkHash8Bytes 18.37 22.80 1.24x
SHA256 BenchmarkHash8Bytes 11.86 13.78 1.16x
SHA512 BenchmarkHash8Bytes 4.51 5.24 1.16x
benchmark old ns/op new ns/op delta
SHA1 BenchmarkHash8Bytes 435 350 -19.54%
SHA256 BenchmarkHash8Bytes 674 580 -13.95%
SHA512 BenchmarkHash8Bytes 1772 1526 -13.88%
R=agl, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/35840044
No change to the meaning, just bad writing found by
Doug McIlroy.
Let's start the new year off with a bang.
R=golang-codereviews, bradfitz, dave
CC=golang-codereviews
https://golang.org/cl/47110044
Most BSDs include the trailing NUL character of the socket path in the
length, however some do not (such as NetBSD 6.99). Handle this by only
subtracting the family and length bytes from the returned length, then
scanning the path and removing any terminating NUL bytes.
Fixes#6627.
R=golang-codereviews, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/46420044
Some builders broke on this test; I'm guessing that was because
this test didn't try hard enough to find a different iteration order.
Update #6719
R=dave
CC=golang-codereviews
https://golang.org/cl/47300043
Technically the spec does not guarantee that the iteration order is random,
but it is a property that we have consciously pursued, and so it seems
right to verify that our implementation does indeed randomise.
Update #6719.
R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/47010043
This source file, when compiled with gcc 4.4.3 on Ubuntu lucid,
corresponds instruction for instruction to the binaries in the same
directory.
Shipping this source code file resolves http://bugs.debian.org/716853
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/46780043
This change fixes a serious performance regression
with reflect.Value growing to 4 words instead of 3.
The json benchmark was ~50% slower, with this change
it is ~5% slower (and the binary is 0.5% larger).
Longer term, we probably need to rethink our copy
generation. Using REP is really expensive time-wise.
But inlining the copy grows the binary.
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/44990043
