All the BSDs and Solaris support the utimensat syscall, but Darwin
doesn't. Account for that by adding the //sys lines not to
syscall_bsd.go but the individual OS's syscall_*.go files and implement
utimensat on Darwin as just returning ENOSYS, such that UtimesNano will
fall back to use utimes as it currently does unconditionally.

This also adds the previously missing utimensat syscall number for
FreeBSD and Dragonfly.

Fixes #16480

Change-Id: I367454c6168eb1f7150b988fa16cf02abff42f34
Reviewed-on: https://go-review.googlesource.com/55130Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

lookupName is only called in one location, and one of the return
values is unused, so let's remove it.

Change-Id: I35e22c7ec611e8eb349deb4f0561e212f7d9de0b
Reviewed-on: https://go-review.googlesource.com/55232Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>

This reverts commit f612cd70.

Reason for revert: We thought the original change had broken the
linux/amd64 and linux/386 builders, but it turned out to be a problem
with the build infrastructure, not the change.

Change-Id: Ic3318a63464fcba8d845ac04494115a7ba620364
Reviewed-on: https://go-review.googlesource.com/55050
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Invert the condition and continue, to remove indentation.

Change-Id: Id62a5d9abc9a4df1193bcf15f95f70f2c2e2abac
Reviewed-on: https://go-review.googlesource.com/55091
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>

This generates better code.

Masking B in the return statement should be unnecessary,
but the compiler is understandably not yet clever enough to see that.

Someday, it'd also be nice for the compiler to generate
a CMOV for the saturation if statement.

Change-Id: Ie1c157b21f5212610da1f3c7823a93816b3b61b9
Reviewed-on: https://go-review.googlesource.com/54656
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>

Shrinks evacuate's machine code a little.

Change-Id: I08874c92abdc7e621bc0737e22f2a6be31542cab
Reviewed-on: https://go-review.googlesource.com/54652
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>

Combine conditions into a single if statement.
This is more readable.

It should generate identical machine code, but it doesn't.
The new code is shorter.

Change-Id: I9bf52f8f288b0df97a2b9b4e4183f6ca74175e8a
Reviewed-on: https://go-review.googlesource.com/54651
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>

This reduces the wall time to run these benchmarks by about 30%.

Change-Id: I494a93c93e5acb1514510d85f65796f62e1629a5
Reviewed-on: https://go-review.googlesource.com/54650
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>

Currently we only support finding symbols in the VDSO using the old
DT_HASH. These days everything uses DT_GNU_HASH instead. To keep up
with the times and future-proof against DT_HASH disappearing from the
VDSO in the future, this commit adds support for DT_GNU_HASH and
prefers it over DT_HASH.

Tested by making sure it found a DT_GNU_HASH section and all of the
expected symbols in it, and then disabling the DT_GNU_HASH path and
making sure the old DT_HASH path still found all of the symbols.

Fixes #19649.

Change-Id: I508c8b35a019330d2c32f04f3833b69cb2686f13
Reviewed-on: https://go-review.googlesource.com/45511
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The ZIP format uses uint16 to contain the length of the file name and
the length of the Extra section. This change verifies that the length
of these fields fit in an uint16 prior to writing the ZIP file. If not,
an error is returned.

Fixes #17402

Change-Id: Ief9a864d2fe16b89ddb9917838283b801a2c58a4
Reviewed-on: https://go-review.googlesource.com/50250Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

If needed cast the test table values to a higher bit size
integer type instead of casting the result values of the
tested function to a lower bit size integer type.

Change-Id: Iaa79742b2b1d90c7c7eac324f54032ebea0b1b41
Reviewed-on: https://go-review.googlesource.com/55137Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

Increases performance of FieldsFunc by recording the start and end
of the fields in an array. The first 32 fields are saved in a pre-allocated
array on the stack. This avoids the old behavior of iterating over the
input string two times but uses more allocations when more than 32 fields
are encountered.

Additionally code for handling non-ASCII containing strings from Fields is
removed and replaced by a call to the new faster FieldsFunc function.

Overall this still leads to a slowdown for Fields on non-ASCII strings
while speeding up Fields in general.

name                      old time/op    new time/op     delta
Fields/ASCII/16              116ns ± 5%      115ns ± 5%       ~     (p=0.480 n=10+10)
Fields/ASCII/256             765ns ± 1%      761ns ± 2%       ~     (p=0.171 n=10+10)
Fields/ASCII/4096           12.5µs ± 1%     12.7µs ± 1%     +1.82%  (p=0.000 n=10+10)
Fields/ASCII/65536           226µs ± 1%      226µs ± 2%       ~     (p=0.739 n=10+10)
Fields/ASCII/1048576        5.12ms ± 1%     5.12ms ± 1%       ~     (p=0.696 n=8+10)
Fields/Mixed/16              172ns ± 1%      233ns ± 1%    +35.90%  (p=0.000 n=9+10)
Fields/Mixed/256            1.18µs ± 2%     2.45µs ± 1%   +107.47%  (p=0.000 n=10+10)
Fields/Mixed/4096           20.3µs ± 1%     43.1µs ± 2%   +112.41%  (p=0.000 n=10+10)
Fields/Mixed/65536           364µs ± 1%      704µs ± 1%    +93.56%  (p=0.000 n=9+10)
Fields/Mixed/1048576        7.07ms ± 2%    13.34ms ± 4%    +88.83%  (p=0.000 n=10+10)
FieldsFunc/ASCII/16          274ns ± 1%      188ns ± 3%    -31.44%  (p=0.000 n=10+10)
FieldsFunc/ASCII/256        3.69µs ± 1%     2.06µs ± 2%    -44.26%  (p=0.000 n=10+10)
FieldsFunc/ASCII/4096       59.9µs ± 1%     35.3µs ± 2%    -41.10%  (p=0.000 n=10+10)
FieldsFunc/ASCII/65536       958µs ± 1%      567µs ± 1%    -40.82%  (p=0.000 n=10+9)
FieldsFunc/ASCII/1048576    16.3ms ± 2%     11.0ms ± 3%    -32.52%  (p=0.000 n=10+10)
FieldsFunc/Mixed/16          309ns ± 1%      213ns ± 0%    -30.98%  (p=0.000 n=10+6)
FieldsFunc/Mixed/256        3.83µs ± 1%     2.14µs ± 1%    -44.01%  (p=0.000 n=10+10)
FieldsFunc/Mixed/4096       66.2µs ± 2%     37.8µs ± 1%    -42.85%  (p=0.000 n=10+10)
FieldsFunc/Mixed/65536      1.09ms ± 1%     0.63ms ± 1%    -42.73%  (p=0.000 n=10+10)
FieldsFunc/Mixed/1048576    18.6ms ± 3%     12.0ms ± 2%    -35.50%  (p=0.000 n=10+10)

Fixes #17856
Fixes #19789

Change-Id: I9f5a560e534566fd81963651f342c8f44cfb0469
Reviewed-on: https://go-review.googlesource.com/42810Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

If the value corresponding to the input string cannot be
represented by an unsigned integer of the given size,
err.Err = ErrRange and the returned value is the maximum
magnitude unsigned integer of the appropriate bitSize.
This is consistent with ParseInt's behavior and the documentation.

Expand tests to test 32 bit test value tables with bitsize 32 set.
These tests fail without the fix in this CL.

Fixes #21278

Change-Id: I8aab39279ec3e31905fcbf582a916cbf6d9b95da
Reviewed-on: https://go-review.googlesource.com/55134
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

Use a simple []byte instead of bytes.Buffer to create a string.
Use bytes.IndexByte instead of our own for loop.

Change-Id: Ic4a1161d79017fd3af086a05c53d5f20a5f09326
Reviewed-on: https://go-review.googlesource.com/54752Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>

By replacing fmt.Sprintf with a simple string concat, we see
pretty good improvements across the board on time and memory.

name             old time/op    new time/op    delta
FormatPAXRecord     683ns ± 2%     210ns ± 5%  -69.22%  (p=0.000 n=10+10)

name             old alloc/op   new alloc/op   delta
FormatPAXRecord      112B ± 0%       32B ± 0%  -71.43%  (p=0.000 n=10+10)

name             old allocs/op  new allocs/op  delta
FormatPAXRecord      8.00 ± 0%      2.00 ± 0%  -75.00%  (p=0.000 n=10+10)

Ran with - -cpu=1 -count=10 on an AMD64 i5-5200U CPU @ 2.20GHz

Using the following benchmark:
func BenchmarkFormatPAXRecord(b *testing.B) {
  for n := 0; n < b.N; n++ {
    formatPAXRecord("foo", "bar")
  }
}

Change-Id: I828ddbafad2e5d937f0cf5f777b512638344acfc
Reviewed-on: https://go-review.googlesource.com/55210Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

Rather than going through the complicated logic of writeHeader,
implement a writeUSTARHeader that only knows about the USTAR format.
This makes the logic much easier to reason about since you only
need to be concerned about USTAR and not all the subtle
differences between USTAR, PAX, and GNU.

We seperate out the logic in writeUSTARHeader into templateV7Plus
and writeRawHeader since the planned implementations of
writePAXHeader and writeGNUHeader will use them.

Change-Id: Ie75a54ac998420ece82686159ae6fa39f8b128e9
Reviewed-on: https://go-review.googlesource.com/54970Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I27ff99aa7abb070f6ae79c8f964aa9bd6a83b89d
Reviewed-on: https://go-review.googlesource.com/53730Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Ensure that we can index maps whose key types are:
* int
* uint
* int32
* uint32
* int64
* uint64
* uintptr

Fixes #20439

Change-Id: I8fa96b14073c8af72786482ff4ffc3508064ea86
Reviewed-on: https://go-review.googlesource.com/43850
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The dieFromSignal runtime function attempts to forward crashing
signals to a signal handler registered before the runtime was
initialized, if any. However, on Darwin, a special signal handler
trampoline is invoked, even for non-Go signal handlers.

Clear the crashing signal's handlingSig entry to ensure sigtramp
forwards the signal.

Fixes the darwin/386 builder.

Updates #20392
Updates #19389

Change-Id: I441a3d30c672cdb21ed6d8f1e1322d7c0e5b9669
Reviewed-on: https://go-review.googlesource.com/55032
Run-TryBot: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

According to http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_key_create.html,
pthread_key_create return an error number which is greater than or equal
to 0. I don't know the scenario that pthread_setspecific would fail, but
also don't know the future. Add some error handlings just in case.

Change-Id: I0774b79ef658d67e300f4a9aab1f2e3879acc7ee
Reviewed-on: https://go-review.googlesource.com/54811Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Intrinsic enabled on all architectures,
runtime asm implementation removed on all architectures.

Fixes #21258

Change-Id: I2cb86d460b497c2f287a5b3df5c37fdb231c23a7
Reviewed-on: https://go-review.googlesource.com/53411Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: David Chase <drchase@google.com>

$ go tool -h says:

  For more about each tool command, see 'go tool command -h'.

but it was suggested to change the suggestion to say:

  see 'go doc command'

In #18313.

That would work for every tool except dist, which has no doc.go.

This change adds a doc.go file to cmd/dist.

Updates #18313

Change-Id: If67a21934b87647a69359d9c14d8de3775c587b7
Reviewed-on: https://go-review.googlesource.com/54351
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently all trace slices get shifted to start at time 0. This makes
it very difficult to find specific points in time unless they fall in
the first slice.

For example, right now when you click "View trace
(6.005646218s-8.155419698s)" on the trace tool's main page, the trace
view puts the first event in that slice at time 0. If you're looking
for something that happened at time 7s, you have to look at time
0.9943537s in the trace view. And if you want to subtract times taken
from different slices, you have to figure out what those time really
correspond to.

Fix this by telling the trace viewer not to shift the times when it
imports the trace. In the above example, this makes the view of that
second trace slice start at time 6.005646218s, so you don't have to do
any gymnastics to find or calculate times in later slices.

Change-Id: I04e0afda60f5573fdd8ad96238c24013297ef263
Reviewed-on: https://go-review.googlesource.com/54633Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

This updates the HTML served for the trace viewer to follow the latest
revision of the example from the upstream tracing project.

The main thing this adds is CSS for the trace viewer (which was
actually in the example at the originally referenced revision, so I'm
not sure why it got dropped). In particular, this expands the trace
viewer to use the entire browser client area, which fixes several
problems with the current page:

1. The details pane gets cut off at a strange place and can get a
scroll bar even if there's plenty of room below it on the page. This
fixes the bottom of the details pane to the bottom of the window.

2. If the track view is very tall (lots of procs), there's no way to
view the top tracks and the details pane at the same time. This fixes
this problem by limiting the height of the track view to something
less than the height of the window so it gets a scroll bar of its own
if necessary.

3. Dragging the divider between the track pane and the details pane
actually moves the bottom of the details pane without moving the
divider. Fixing the height of the trace viewer fixes this problem.

Change-Id: Ia811e72a7413417ca21c45e932c9db2724974633
Reviewed-on: https://go-review.googlesource.com/54632
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

_main has an early check to verify if a binary is statically or dynamically
linked that depends on R0 being zero. R0 is not guaranteed to be zero at that
point and this was breaking Go on Alpine for ppc64le.

Change-Id: I4a1059ff7fd3db6fc489e7dcfe631c1814dd965b
Reviewed-on: https://go-review.googlesource.com/54730
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>

The gofmt bug in question seems to be fixed (at least gofmt doesn't
complain), so reenable the commented-out ... test.

Change-Id: Icbfe0511160210557894ec8eb9b206aa6133d486
Reviewed-on: https://go-review.googlesource.com/55030
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This implements trunc, floor, and ceil in the math package
as intrinsics on ppc64x.  Significant improvement mainly due
to avoiding call overhead of args and return value.

BenchmarkCeil-16                    5.95          0.69          -88.40%
BenchmarkFloor-16                   5.95          0.69          -88.40%
BenchmarkTrunc-16                   5.82          0.69          -88.14%

Updates #21390

Change-Id: I951e182694f6e0c431da79c577272b81fb0ebad0
Reviewed-on: https://go-review.googlesource.com/54654
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>

Change-Id: I85df2745af666b533f4f6f1d06f7c8e137590b5b

This change adds a better implementation in asm for AddMulVVW and
mulAddVWW for ppc64x, with speedups up to 1.54x.

benchmark                       old ns/op     new ns/op     delta
BenchmarkAddMulVVW/1-8          6.58          6.29          -4.41%
BenchmarkAddMulVVW/2-8          7.43          7.25          -2.42%
BenchmarkAddMulVVW/3-8          8.95          8.15          -8.94%
BenchmarkAddMulVVW/4-8          10.1          9.37          -7.23%
BenchmarkAddMulVVW/5-8          12.0          10.7          -10.83%
BenchmarkAddMulVVW/10-8         22.1          20.1          -9.05%
BenchmarkAddMulVVW/100-8        211           154           -27.01%
BenchmarkAddMulVVW/1000-8       2046          1450          -29.13%
BenchmarkAddMulVVW/10000-8      20407         14793         -27.51%
BenchmarkAddMulVVW/100000-8     223857        145548        -34.98%

benchmark                       old MB/s     new MB/s     speedup
BenchmarkAddMulVVW/1-8          9719.88      10175.79     1.05x
BenchmarkAddMulVVW/2-8          17233.97     17657.54     1.02x
BenchmarkAddMulVVW/3-8          21446.05     23550.49     1.10x
BenchmarkAddMulVVW/4-8          25375.70     27334.33     1.08x
BenchmarkAddMulVVW/5-8          26650.52     30029.34     1.13x
BenchmarkAddMulVVW/10-8         28984.29     31833.68     1.10x
BenchmarkAddMulVVW/100-8        30249.41     41531.69     1.37x
BenchmarkAddMulVVW/1000-8       31273.35     44108.54     1.41x
BenchmarkAddMulVVW/10000-8      31360.47     43263.54     1.38x
BenchmarkAddMulVVW/100000-8     28589.58     43971.66     1.54x

Change-Id: I8a8105d4da3592afdef3125757a99f378a0254bb
Reviewed-on: https://go-review.googlesource.com/53931
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>

Change-Id: Icdd0566d3b7dbc034256e16f8a6b6f1af07069b3
Reviewed-on: https://go-review.googlesource.com/54350Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

As noted in the TODO comment, the sticky bit is only used
when the rounding bit is zero or the rounding mode is
ToNearestEven.  This change makes that check explicit and
will eliminate half the sticky bit calculations on average
when rounding mode is not ToNearestEven.

Change-Id: Ia4709f08f46e682bf97dabe5eb2a10e8e3d7af43
Reviewed-on: https://go-review.googlesource.com/54111Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

Although mincore is declared in stubs.go, mincore isn't used by any
OSes except linux. Move it to os_linux.go and clean up unused code.

Change-Id: I6cfb0fed85c0317a4d091a2722ac55fa79fc7c9a
Reviewed-on: https://go-review.googlesource.com/54910Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This parameter is always false. The last occurrence of s.skipSpace(true)
was removed in mid-2015.

While at it, merge skipSpace into SkipSpace, since the latter was just a
wrapper without the parameter.

Found with github.com/mvdan/unparam.

Change-Id: I884ea4036f41234a898d6aeee515211c49b0b435
Reviewed-on: https://go-review.googlesource.com/52890Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>

Change-Id: Ib5356181c3204c8f9922eeb4da1c06bfdb18f443
Reviewed-on: https://go-review.googlesource.com/54812Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I8d295ea32bf56adc42171947133f3e16a88664c6
Reviewed-on: https://go-review.googlesource.com/54911Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The current logic in writeHeader attempts to encode the Header in one
format and if it discovered that it could not it would attempt to
switch to a different format mid-way through. This makes it very
hard to reason about what format will be used in the end and whether
it will even be a valid format.

Instead, we should verify from the start what formats are allowed
to encode the given input Header. If no formats are possible,
then we can return immediately, rejecting the Header.

For now, we continue on to the hairy logic in writeHeader, but
a future CL can split that logic up and specialize them for each
format now that we know what is possible.

Update #9683
Update #12594

Change-Id: I8406ea855dfcb8b478a03a7058ddf8b2b09d46dc
Reviewed-on: https://go-review.googlesource.com/54433
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

I also wanted to test net sockets, but I do not know how to
access their file handles. So I did not implement socket tests.

Updates #21172

Change-Id: I5062c0e65a817571d755397d60762c175f9791ce
Reviewed-on: https://go-review.googlesource.com/53530Reviewed-by: Ian Lance Taylor <iant@golang.org>

The prior logic would over-write the NUL-terminator if the octal value
was long enough. In order to prevent this, we add a fitsInOctal function
that does the proper check.

The relevant USTAR specification about NUL-terminator is:
<<<
Each numeric field is terminated by one or more <space> or NUL characters.
>>>

Change-Id: I6fbc6e8fe71168727eea201925d0fe08d43116ac
Reviewed-on: https://go-review.googlesource.com/54432Reviewed-by: Ian Lance Taylor <iant@golang.org>

USTAR and GNU strings are NUL-terminated. Thus, we should never
allow the NUL terminator, otherwise we will lose data round-trip.

Relevant specification text:
<<<
The fields magic, uname, and gname are character strings each terminated by a NUL character.
>
> Technically, PAX keys and values should be UTF-8, but the observance
> of invalid files in the wild causes us to be more liberal.
> <<<
> The <length> field, <blank>, <equals-sign>, and <newline> shown shall
> be limited to the portable character set, as encoded in UTF-8.

Thus, we only reject NULs in PAX keys, and NULs for PAX values
representing the USTAR string fields (i.e., path, linkpath, uname, gname).
These are treated more strictly because they represent strings that
are typically represented as C-strings on POSIX systems.

Change-Id: I305b794d9d966faad852ff660bd0b3b0964e52bf
Reviewed-on: https://go-review.googlesource.com/14724
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>