delta/go-git.git/src/encoding, branch dev.boringcrypto.go1.12

encoding/json: add comment for mashalererror struct

2019-01-15T23:30:58+00:00

Change-Id: Iaabbfe5a4c1bbedd19d4087f1b79e5a38bdd3878
GitHub-Last-Rev: 55c91fc19074dacc66623aa7ff2286b11ccd5340
GitHub-Pull-Request: golang/go#29752
Reviewed-on: https://go-review.googlesource.com/c/157958
Reviewed-by: Ian Lance Taylor

encoding/gob: mention that Encoder and Decoder are safe for concurrent use

2018-12-28T22:14:11+00:00

Fixes #29416

Change-Id: I24364bfee77aceace53f85f1046ef4d73f8feebb

Change-Id: I24364bfee77aceace53f85f1046ef4d73f8feebb
GitHub-Last-Rev: ad9f31145763dc16f53dd9f3154667b162759f69
GitHub-Pull-Request: golang/go#29417
Reviewed-on: https://go-review.googlesource.com/c/155742
Reviewed-by: Ian Lance Taylor

encoding/xml, encoding/json: docs and examples using custom marshalers

2018-12-12T14:18:06+00:00

Both the encoding/xml and encoding/json packages support custom
marshalers for JSON and XML, as well as the basic encoding.TextMarshaler
and encoding.TextUnmarshaler interfaces, but the docs and examples for
these are missing.

There are docs for how to use encoding.TextMarshaler and
encoding.TextUnmarshaler in encoding/json, but not encoding/xml. There
are no examples for how to use them with either json or xml. This commit
includes docs for encoding/xml and examples for both encoding/json and
encoding/xml.

There is an example using custom marshalers MarshalJSON and
UnmarshalJSON in encoding/json, but not MarshalXML and UnmarshalXML in
encoding/json. These docs are more so necessary for encoding/xml because
the complexities of XML documents is significantly greater than JSON
documents which more often leads to the need for custom marshaling. The
encoding/json package includes an example of how to write a custom
marshaler, and this commit includes the same example for the xml
package.

All examples are mirrored off the existing custom marshaler example in
encoding/json.

Fixes #6859

Change-Id: Ic93abc27c0b4d5e48dea6ede4e20b1bedca4ab39
Reviewed-on: https://go-review.googlesource.com/c/76350
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

encoding/pem: test getLine does not include trailing whitespace

2018-11-19T23:35:21+00:00

Change-Id: I7a1046f5e0aedbbdd1106a616de410fe4e0cb7d8
Reviewed-on: https://go-review.googlesource.com/c/92295
Run-TryBot: Ian Lance Taylor 
Reviewed-by: Ian Lance Taylor

all: use "reports whether" consistently in the few places that didn't

2018-11-02T22:47:58+00:00

Go documentation style for boolean funcs is to say:

    // Foo reports whether ...
    func Foo() bool

(rather than "returns true if")

This CL also replaces 4 uses of "iff" with the same "reports whether"
wording, which doesn't lose any meaning, and will prevent people from
sending typo fixes when they don't realize it's "if and only if". In
the past I think we've had the typo CLs updated to just say "reports
whether". So do them all at once.

(Inspired by the addition of another "returns true if" in CL 146938
in fd_plan9.go)

Created with:

$ perl -i -npe 's/returns true if/reports whether/' $(git grep -l "returns true iff" | grep -v vendor)
$ perl -i -npe 's/returns true if/reports whether/' $(git grep -l "returns true if" | grep -v vendor)

Change-Id: Ided502237f5ab0d25cb625dbab12529c361a8b9f
Reviewed-on: https://go-review.googlesource.com/c/147037
Reviewed-by: Ian Lance Taylor

encoding/json: add example to Valid

2018-10-28T19:49:25+00:00

Change-Id: I411483d76a2ca91cd15ff42ae1adb9134486d183
Reviewed-on: https://go-review.googlesource.com/c/145278
Reviewed-by: Brad Fitzpatrick 
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

encoding/gob: delete out of memory test

2018-10-22T22:23:03+00:00

Now that the library allows much larger data, it can kill
machines with less memory.

Fixes #28321

Change-Id: I98e1a5fdf812fd75adfb22bf01542423de405fe2
Reviewed-on: https://go-review.googlesource.com/c/143817
Reviewed-by: Ian Lance Taylor 
Reviewed-by: Dmitri Shuralyov

encoding/gob: increase "tooBig" from 1GB to 8GB on 64-bit machines

2018-10-22T05:45:18+00:00

A little shift magic makes it easy to adjust the maximum buffer
size on machines with larger integers.

Fixes #27635

Change-Id: I1f26b07a363fbb9730df2377052475fa88bbb781
Reviewed-on: https://go-review.googlesource.com/c/143678
Run-TryBot: Rob Pike 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

encoding/json: always verify we can get a field's value

2018-10-16T14:02:52+00:00

Calling .Interface on a struct field's reflect.Value isn't always safe.
For example, if that field is an unexported anonymous struct.

We only descended into this branch if the struct type had any methods,
so this bug had gone unnoticed for a few release cycles.

Add the check, and add a simple test case.

Fixes #28145.

Change-Id: I02f7e0ab9a4a0c18a5e2164211922fe9c3d30f64
Reviewed-on: https://go-review.googlesource.com/c/141537
Run-TryBot: Daniel Martí 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

encoding/json: fix "data changed underfoot?" panic

2018-10-16T13:45:08+00:00

Given a program as follows:

	data := []byte(`{"F": {
		"a": 2,
		"3": 4
	}}`)
	json.Unmarshal(data, &map[string]map[int]int{})

The JSON package should error, as "a" is not a valid integer. However,
we'd encounter a panic:

	panic: JSON decoder out of sync - data changing underfoot?

The reason was that decodeState.object would return a nil error on
encountering the invalid map key string, while saving the key type error
for later. This broke if we were inside another object, as we would
abruptly end parsing the nested object, leaving the decoder in an
unexpected state.

To fix this, simply avoid storing the map element and continue decoding
the object, to leave the decoder state exactly as if we hadn't seen an
invalid key type.

This affected both signed and unsigned integer keys, so fix both and add
two test cases.

Updates #28189.

Change-Id: I8a6204cc3ff9fb04ed769df7a20a824c8b94faff
Reviewed-on: https://go-review.googlesource.com/c/142518
Reviewed-by: Ian Lance Taylor