Followup to CL 16047.
For #12963.
Change-Id: I596cd5109b25a4079b966427411860fde8b9b54a
Reviewed-on: https://go-review.googlesource.com/17232
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The empty string is not a valid DER integer. DER also requires that values be
minimally-encoded, so excess padding with leading 0s (0xff for negative
numbers) is forbidden. (These rules also apply to BER, incidentally.)
Fixes#12622.
Change-Id: I041f94e34a8afa29dbf94dd8fc450944bc91c9c3
Reviewed-on: https://go-review.googlesource.com/17008
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
From the XML spec: "XML processors should match character encoding
names in a case-insensitive way"
Fixes#12417.
Change-Id: I678c50152a49c14364be62b3f21ab9b9b009b24b
Reviewed-on: https://go-review.googlesource.com/14084
Reviewed-by: Russ Cox <rsc@golang.org>
json.Number is a special case which didn't have any checks and could result in invalid JSON.
Fixes#10281
Change-Id: Ie3e726e4d6bf6a6aba535d36f6107013ceac913a
Reviewed-on: https://go-review.googlesource.com/12250
Reviewed-by: Russ Cox <rsc@golang.org>
BER allows the sender to choose either short form or long form where
both are legal, but DER requires the minimal one be used. Enforce this
and add a test. Fix one test which was not minimally-encoded and another
which would not distinguish rejecting the input because the long form
length wasn't minimally-encoded from rejecting it because long form was
chosen when short form was allowed.
Change-Id: I1b56fcca594dcdeddea9378b4fab427cbe7cd26d
Reviewed-on: https://go-review.googlesource.com/16517
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
This allows slices of custom types with byte as underlying type to be
decoded, fixing a regression introduced in CL 9371.
Fixes#12921.
Change-Id: I62a715eaeaaa912b6bc599e94f9981a9ba5cb242
Reviewed-on: https://go-review.googlesource.com/16303
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change-Id: I1da1d718609eb6a7b78d29b173ec780bde22c687
Reviewed-on: https://go-review.googlesource.com/16422
Reviewed-by: Ralph Corderoy <ralph@inputplus.co.uk>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Addresses issue #12367.
Must be checked in before CL 14010.
Change-Id: I4523a1de112ed02371504e27882659bce8028a9f
Reviewed-on: https://go-review.googlesource.com/14012
Reviewed-by: Russ Cox <rsc@golang.org>
Addresses issue #12367.
Must be checked in before CL 14010.
Change-Id: I7233c3a62d4f55d0ac7e8a87df5fc4ee7beb7207
Reviewed-on: https://go-review.googlesource.com/14011
Reviewed-by: Russ Cox <rsc@golang.org>
As correctly mentioned in #11883, encodeState.string and
encodeState.stringBytes never return an error.
This CL removes the error from the function signatures and somewhat
simplifies call sites.
Fixes#11883
Change-Id: I1d1853d09631c545b68b5eea86ff7daa2e0ca10b
Reviewed-on: https://go-review.googlesource.com/15836
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The documentation listing err == EOF can be confusing to newcomers
to the language who are looking for the relevant documentation for
that error.
Change-Id: I301885950d0e1d0fbdf3a1892fca86eac7a0c616
Reviewed-on: https://go-review.googlesource.com/15806
Reviewed-by: Andrew Gerrand <adg@golang.org>
Also add a unit test to lock this behavior into the API.
Fixes#12016
Change-Id: Ib6ec6e7948f0705f3504ede9143b5dc4e790fc44
Reviewed-on: https://go-review.googlesource.com/15171
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The fields step and redoState of struct scanner are now defined as
`func(s *scanner, c byte) int` instead of
`func(s *scanner, c int) int`, since bytes are sufficient.
Further changes improve the consistency in the scanner.go file.
Change-Id: Ifb85f2130d728d2b936d79914d87a1f0b5c6ee7d
Reviewed-on: https://go-review.googlesource.com/14801
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is understood, obvious (to me), and well known but has not been clearly documented.
Fixes#11117.
Change-Id: Ib2b1e318924748d1eac0d735ad6286533be7fd39
Reviewed-on: https://go-review.googlesource.com/14693
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, the xml.Decoder's Token routine returns successfully for
XML input that does not properly close root start elements (and any
unclosed descendants). For example, all the following inputs
<root>
<root><foo>
<root><foo></foo>
cause Token to return with nil and io.EOF, indicating a successful
parse.
This change fixes that. It leaves the semantics of RawToken intact.
Fixes#11405
Change-Id: I6f1328c410cf41e17de0a93cf357a69f12c2a9f7
Reviewed-on: https://go-review.googlesource.com/14315
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This is not a functional change. nr is a uint64 and can never be less
than zero, remove the no-op comparison.
Fixes#11279
Change-Id: Iebb36cc8fe97428b503e65d01b5e67d2b2bc7369
Reviewed-on: https://go-review.googlesource.com/13876
Run-TryBot: Todd Neal <todd@tneal.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Could go in 1.5, although not critical.
See also #12107
Change-Id: I7f1608b58581d21df4db58f0db654fef79e33a90
Reviewed-on: https://go-review.googlesource.com/13481
Reviewed-by: Dave Cheney <dave@cheney.net>
Rename test name from Http to HTTP, and fix some style nits.
Change-Id: I00fe1cecd69ca2f50be86a76ec90031c2f921707
Reviewed-on: https://go-review.googlesource.com/12760
Reviewed-by: Andrew Gerrand <adg@golang.org>
The new Token API is meant to sit on the side of the Decoder,
so that you only get the new code (and any latent bugs in it)
if you are actively using the Token API.
The unconditional use of dec.peek in dec.tokenPrepareForDecode
violates that intention.
Change tokenPrepareForDecode not to call dec.peek unless needed
(because the Token API has advanced the state).
This restores the old code path behavior, no peeking allowed.
I checked by patching in the new tests from CL 12726 that
this change suffices to "fix" the error handling bug in dec.peek.
Obviously that bug should be fixed too, but the point is that
with this CL, bugs in dec.peek do not affect plain use of Decode
or Unmarshal.
I also checked by putting a panic in dec.peek that the only
tests that now invoke peek are:
TestDecodeInStream
ExampleDecoder_Token
ExampleDecoder_Decode_stream
and those tests all invoke dec.Token directly.
Change-Id: I0b242d0cb54a9c830548644670dc5ab5ccef69f2
Reviewed-on: https://go-review.googlesource.com/12740
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Peter Waldschmidt <peter@waldschmidt.com>
This race was identified in #9796, but a sequence of fixes
proposed in golang.org/cl/4152 were rolled into
golang.org/cl/5910 which both fixed the race and
modified the name space behavior.
We rolled back the name space changes and lost the race fix.
Fix the race separate from the name space changes,
following the suggestion made by Roger Peppe in
https://go-review.googlesource.com/#/c/4152/7/src/encoding/xml/marshal.go@897Fixes#9796.
Fixes#11885.
Change-Id: Ib2b68982da83dee9e04db8b8465a8295259bba46
Reviewed-on: https://go-review.googlesource.com/12687
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This change adds new methods to Decoder.
* Decoder.Token steps through a JSON document, returning a value for each token.
* Decoder.Decode unmarshals the entire value at the token stream's current
position (in addition to its existing function in a stream of JSON values)
Fixes#6050.
Fixes#6499.
Change-Id: Iff283e0e7b537221ae256392aca6529f06ebe211
Reviewed-on: https://go-review.googlesource.com/9073
Reviewed-by: Russ Cox <rsc@golang.org>
There is clearly work to do here with respect to xml name spaces,
but I don't believe the changes in this cycle are clearly correct.
The changes in this cycle have visible impact on the generated xml,
possibly breaking existing programs, and yet it's not clear that they
are the end of the story: there is still significant confusion about how
name spaces work or should work (see #9519, #9775, #8167, #7113).
I would like to wait to make breaking changes until we completely
understand what the behavior should be and can evaluate the benefit
of those breaking changes. My main concern here is that we will break
programs in Go 1.5 for the sake of name space adjustments and then
while trying to fix those other bugs we'll break programs in Go 1.6 too.
Let's wait until we know all the changes we want to make before we
decide whether or how to break existing programs.
This CL reverts:
5ae822b encoding/xml: minor changes
bb7e665 encoding/xml: fix xmlns= behavior
9f9d66d encoding/xml: fix default namespace of tags
b69ea01 encoding/xml: fix namespaces in a>b tags
3be158d encoding/xml: encoding name spaces correctly
and adjusts tests from
a9dddb5 encoding/xml: add more EncodeToken tests.
to expect Go 1.4 behavior.
I have confirmed that the name space parts of the test suite
as of this CL passes against the Go 1.4 encoding/xml package,
indicating that this CL successfully restores the Go 1.4 behavior.
(Other tests do not, but that's because there were some real
bug fixes in this cycle that are being kept. Specifically, the
tests that don't pass in Go 1.4 are TestMarshal's NestedAndComment
case, TestEncodeToken's encoding of newlines, and
TestSimpleUseOfEncodeToken returning an error for invalid
token types.)
I also checked that the Go 1.4 tests pass when run against
this copy of the sources.
Fixes#11841.
Change-Id: I97de06761038b40388ef6e3a55547ff43edee7cb
Reviewed-on: https://go-review.googlesource.com/12570
Reviewed-by: Nigel Tao <nigeltao@golang.org>
EncodeToken takes a Token (i.e. an interface{}) as a parameter,
and expects a value of type StartElement, EndElement, CharData,
Comment, ProcInst, or Directive.
If a pointer is passed instead, or any type which does not match
this list, the token is silently ignored.
Added a default case in the type switch to issue a proper error
when the type is invalid.
The behavior could be later improved by allowing pointers to
token to be accepted as well, but not for go1.5.
Fixes#11719
Change-Id: Ifd13c1563450b474acf66d57669fdccba76c1949
Reviewed-on: https://go-review.googlesource.com/12252
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
JSON decoding currently fails for null values bound to any type
which does implement the JSON Unmarshaler interface without checking
for null values (such as time.Time).
It also fails for types implementing the TextUnmarshaler interface.
The expected behavior of the JSON decoding engine in such case is
to process null by keeping the value unchanged without producing
any error.
Make sure null values are handled by the decoding engine itself,
and never passed to the UnmarshalText or UnmarshalJSON methods.
Fixes#9037
Change-Id: I261d85587ba543ef6f1815555b2af9311034d5bb
Reviewed-on: https://go-review.googlesource.com/9376
Reviewed-by: Russ Cox <rsc@golang.org>
When building a directive, the current sanity check prevents
a '>' to be used, which makes a DOCTYPE directive with an
internal subset be rejected. It is accepted by the parser
though, so what can be parsed cannot be encoded.
Improved the corresponding sanity check to mirror the behavior
of the parser (in the way it handles angle brackets, quotes,
and comments).
Fixes#10158
Change-Id: Ieffea9f870f2694548e12897f8f47babc0ea4414
Reviewed-on: https://go-review.googlesource.com/11630
Reviewed-by: Russ Cox <rsc@golang.org>
The "string" option only applies for strings, floats, integers, and
booleans as per the documentation. So when decoding ignore the "string"
option if the value is not of one of the types mentioned. This matches
the Marshal step which also ignores the "string" option for invalid
types.
Fixes#9812
Change-Id: I0fb2b43d0668bc0e2985886d989abbf2252070e2
Reviewed-on: https://go-review.googlesource.com/10183
Reviewed-by: Russ Cox <rsc@golang.org>
The previous commit (git 2ae77376) just did golang.org. This one
includes golang.org subdomains like blog, play, and build.
Change-Id: I4469f7b307ae2a12ea89323422044e604c5133ae
Reviewed-on: https://go-review.googlesource.com/12071
Reviewed-by: Rob Pike <r@golang.org>
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.
I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.
Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
When an xmlns="..." attribute was explicitly generated,
it was being ignored because the name space on the
attribute was assumed to have been explicitly set (to the empty
name space) and it's not possible to have an element in the
empty name space when there is a non-empty name space set.
We fix this by recording when a default name space has been
explicitly set and setting the name space of the element to that
so printer.defineNS can do its work correctly.
We do not attempt to add our own xmlns="..." attribute
when one is explicitly set.
We also add tests for EncodeElement, as that's the only way
to attain coverage of some of the changed behaviour.
Some other test coverage is also increased, although
more work remains to be done in this area.
This change was jointly developed with Martin Hilton (mhilton on github).
Fixes#11431.
Change-Id: I7b85e06eea5b18b2c15ec16dcbd92a8e1d6a9a4e
Reviewed-on: https://go-review.googlesource.com/11635
Reviewed-by: Russ Cox <rsc@golang.org>
Invalid UTF-8 triggers an error when marshaling but, previously, not
when unmarshaling. This means that ASN.1 structures were not
round-tripping.
This change makes invalid UTF-8 in a string marked as UTF-8 to be an
error when Unmarshaling.
Fixes#11126.
Change-Id: Ic37be84d21dc5c03983525e244d955a8b1e1ff14
Reviewed-on: https://go-review.googlesource.com/11056
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The time package does normalisation of times: for example day zero is
converted to the last day of the previous month and the 31st of February
is moved into March etc. This makes the ASN.1 parsing a little
worryingly lax.
This change causes the parser to reserialise parsed times to ensure that
they round-trip correctly and thus were not normalised.
Fixes#11134.
Change-Id: I3988bb95153a7b33d64ab861fbe51b1a34a359e9
Reviewed-on: https://go-review.googlesource.com/11094
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Check that if a version is declared, for example
in '<?xml version="XX" ?>', version must be '1.0'.
Change-Id: I16ba9f78873a5f31977dcf75ac8e671fe6c08280
Reviewed-on: https://go-review.googlesource.com/8961
Reviewed-by: Russ Cox <rsc@golang.org>
When the scanner receives a non-whitespace character in stateEndTop,
it creates an error message and caches it to return on the next
transition. nextValue() uses the scanner to sub-scan for a value
inside a larger JSON structure. Since stateEndTop is triggered
*after* the ending byte, whatever character immediately follows the
sub-value gets pulled into the scanner's state machine as well.
Even though it is not used and doesn't cause an error, it does
cause the state machine to allocate an error that will never be used.
The fix is to probe the state machine with whitespace after
scanEndObject or scanEndArray to see if the next character would
result in a scanEnd state transition. If so, we can return right
away without processing the next character and avoid triggering
an allocation.
benchmark old ns/op new ns/op delta
BenchmarkCodeEncoder 17022194 16611336 -2.41%
BenchmarkCodeMarshal 18443250 18090144 -1.91%
BenchmarkCodeDecoder 61502053 61010936 -0.80%
BenchmarkCodeUnmarshal 61410829 60363605 -1.71%
BenchmarkCodeUnmarshalReuse 59124836 58361772 -1.29%
BenchmarkUnmarshalString 602 603 +0.17%
BenchmarkUnmarshalFloat64 535 537 +0.37%
BenchmarkUnmarshalInt64 482 482 +0.00%
BenchmarkIssue10335 1206 799 -33.75%
BenchmarkSkipValue 17605751 18355391 +4.26%
BenchmarkEncoderEncode 612 604 -1.31%
benchmark old MB/s new MB/s speedup
BenchmarkCodeEncoder 114.00 116.82 1.02x
BenchmarkCodeMarshal 105.21 107.27 1.02x
BenchmarkCodeDecoder 31.55 31.81 1.01x
BenchmarkCodeUnmarshal 31.60 32.15 1.02x
BenchmarkSkipValue 111.63 107.07 0.96x
benchmark old allocs new allocs delta
BenchmarkIssue10335 11 4 -63.64%
BenchmarkEncoderEncode 2 2 +0.00%
benchmark old bytes new bytes delta
BenchmarkIssue10335 376 272 -27.66%
BenchmarkEncoderEncode 40 40 +0.00%
Fixes#10335
Change-Id: I3d4f2b67f7a038adfb33ba48bb6b680f528baf18
Reviewed-on: https://go-review.googlesource.com/9074
Reviewed-by: Russ Cox <rsc@golang.org>
This was found while fuzzing another program, triggering a panic in
x509.ParseECPrivateKey.
Fixes#11154
Change-Id: Ief35ead38adf14caec4d37b9eacf8a92e67cd1e6
Reviewed-on: https://go-review.googlesource.com/10712
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
These were found by grepping the comments from the go code and feeding
the output to aspell.
Change-Id: Id734d6c8d1938ec3c36bd94a4dbbad577e3ad395
Reviewed-on: https://go-review.googlesource.com/10941
Reviewed-by: Aamir Khan <syst3m.w0rm@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The documentation for quick.Value says that it "returns an arbitrary
value of the given type." In spite of this, nil values for pointers were
never generated, which seems more like an oversight than an intentional
choice.
The lack of nil values meant that testing recursive type like
type Node struct {
Next *Node
}
with testing/quick would lead to a stack overflow since the data
structure would never terminate.
This change may break tests that don't check for nil with pointers
returned from quick.Value. Two such instances were found in the standard
library, one of which was in the testing/quick package itself.
Fixes#8818.
Change-Id: Id390dcce649d12fbbaa801ce6f58f5defed77e60
Reviewed-on: https://go-review.googlesource.com/10821
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
This CL resets the parent stack when printing a character or comment field struct.
In the case of XML elements, the previous parents stack must be considered. However,
charadata or comment fields can't be printed in other fields so it seems required to reset
the parent stack each time a chardata or comment field is printed.
Fixes#5072
Change-Id: I84f61c9bfce94133cd0c076c11211b9be5b4b1ac
Reviewed-on: https://go-review.googlesource.com/9910
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
This was a simple oversight: the algorithm to handle recursive types
needed to be applied to the ignore-item case as well.
Fixes#10415.
Change-Id: I39ef31cad680ab8334e141f60d2f8707896785d1
Reviewed-on: https://go-review.googlesource.com/8942
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
As noted in bug #10980, an empty PEM block is encoded as
-----BEGIN foo-----
-----END foo-----
However, Decode failed to process this.
RFC 1421 doesn't answer what the encoding of the empty block should be
because PEM messages always contain at least one header. However, PEM
these days is just the encoding format – nobody uses the rest of PEM any
longer.
Having the empty block not contain a newline seems most correct because
https://tools.ietf.org/html/rfc1421#section-9 clearly says that the
optional “pemtext” carries the leading new-line with it. So if omitted,
the new-line should be omitted too.
None the less, this changes makes encoding/pem permissive, accepting any
number of blank lines in an empty PEM block.
Fixes#10980
Change-Id: If36bdfbf991ee281eccd50b56ddc95f24c6debb2
Reviewed-on: https://go-review.googlesource.com/10516
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
All slice types which have elements of kind reflect.Uint8 are marshalled
into base64 for compactness. When decoding such data into a custom type
based on []byte the decoder checked the slice kind instead of the slice
element kind, so no appropriate decoder was found.
Fixed by letting the decoder check slice element kind like the encoder.
This guarantees that already encoded data can still be successfully
decoded.
Fixes#8962.
Change-Id: Ia320d4dc2c6e9e5fe6d8dc15788c81da23d20c4f
Reviewed-on: https://go-review.googlesource.com/9371
Reviewed-by: Peter Waldschmidt <peter@waldschmidt.com>
Reviewed-by: Russ Cox <rsc@golang.org>
BenchmarkSkipValue was sensitive to the value of
b.N due to its significant startup cost.
Two adjacent runs before this CL:
BenchmarkSkipValue 50 21047499 ns/op 93.37 MB/s
BenchmarkSkipValue 100 17260554 ns/op 118.05 MB/s
After this CL, using benchtime to recreate the
difference in b.N:
BenchmarkSkipValue 50 15204797 ns/op 131.67 MB/s
BenchmarkSkipValue 100 15332319 ns/op 130.58 MB/s
Change-Id: Iac86f86dd774d535302fa5e4c08f89f8da00be9e
Reviewed-on: https://go-review.googlesource.com/10053
Reviewed-by: Andrew Gerrand <adg@golang.org>
Messages that are too big are rejected when read, so they should
be rejected when written too.
Fixes#10518.
Change-Id: I96678fbe2d94f51b957fe26faef33cd8df3823dd
Reviewed-on: https://go-review.googlesource.com/9965
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change corrects the serialization of asn1.Flag values, so that
when set, they serialize to an empty value, and when unset, they are
omitted. It also adds a format parameter that allows calling code
to control whether time.Time values are serialized as UTCTime or
GeneralizedTime.
Change-Id: I6d97abf009ea317338dab30c80f35a2de7e07104
Reviewed-on: https://go-review.googlesource.com/5970
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
There is no need to escape newlines in char data -
it makes the XML larger and harder to read.
Change-Id: I1c1fcee1bdffc705c7428f89ca90af8085d6fb73
Reviewed-on: https://go-review.googlesource.com/9310
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Currently parseRecord will always start with a nil
slice and then resize the slice on append. For input
with a fixed number of fields per record we can preallocate
the slice to avoid having to resize the slice.
This change implements this optimization by using
FieldsPerRecord as capacity if it's > 0 and also adds a
benchmark to better show the differences.
benchmark old ns/op new ns/op delta
BenchmarkRead 19741 17909 -9.28%
benchmark old allocs new allocs delta
BenchmarkRead 59 41 -30.51%
benchmark old bytes new bytes delta
BenchmarkRead 6276 5844 -6.88%
Change-Id: I7c2abc9c80a23571369bcfcc99a8ffc474eae7ab
Reviewed-on: https://go-review.googlesource.com/8880
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also unify the tests where possible to make it easy to add more.
Fixes#10273.
Change-Id: Idfa4f4a5dcaa05974066bafe17bed6cdd2ebedb7
Reviewed-on: https://go-review.googlesource.com/8662
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When decoding an invalid typeId the associated *decEngine was not
removed from decoderMap. If the decoder was run again on the same input
a nil *decEngine was found in the map and assumed to be initialized,
resulting in a panic.
Fixes#9649
Change-Id: I5bb51808362a21c09228c2705a658f073e5b59b3
Reviewed-on: https://go-review.googlesource.com/3509
Reviewed-by: Rob Pike <r@golang.org>
Fix the other places the slice length was being believed, and refactor
the code to use a single function to unify the check.
Fixes#10273.
Change-Id: Ia62b25203fbe87c95d71a70ebc1db8d202eaa4a4
Reviewed-on: https://go-review.googlesource.com/8511
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
decBuffer.Drop is called using data provided by the user, don't
panic if it's bogus.
Fixes#10272.
Change-Id: I913ae9c3c45cef509f2b8eb02d1efa87fbd52afa
Reviewed-on: https://go-review.googlesource.com/8496
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The debug/dwarf and encoding/asn1 examples were added in 2009, a few
months before Go added implicit semicolons, and never updated.
The go/ast node types have always been named just "Expr", "Stmt", and
"Decl", so the comments about "ExprNode", "StmtNode", and "DeclNode"
were likely just mistaken because the interface tag methods are
"exprNode", "stmtNode", and "declNode", respectively.
Change-Id: I9d138cc3a16c1a51453da1406914d7b320bf6270
Reviewed-on: https://go-review.googlesource.com/7980
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The struct XMLName sets the default namespace, but
that's not good enough for nested tags, because an
earlier tag can set the implicit parents of a subsequent
tag. This change makes sure that we always explicitly set the
namespace on a tag when possible.
See https://go-review.googlesource.com/#/c/5910/4/src/encoding/xml/marshal_test.go@628
for discussion.
Change-Id: If1afc536471c0be83e5dd80381b598476ea3f44d
Reviewed-on: https://go-review.googlesource.com/6927
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Previously, if there was a namespace defined on
a a>b tag, the namespace was ignored when
printing the parent elements. This fixes that,
and also fixes the racy behaviour of printerStack.trim
as discussed in https://go-review.googlesource.com/#/c/4152/10 .
Fixes#9796.
Change-Id: I75f97f67c08bbee151d1e0970f8462dd0f4511ef
Reviewed-on: https://go-review.googlesource.com/5910
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The comment previously was reversed in sense (it appeared to be
describing unmarshaling). I've fixed that, and added the caveat that map
keys are subject to UTF-8 coercion like other strings.
Change-Id: Id08082aa71401a6e7530a42f979fbb50bd1f4e6a
Reviewed-on: https://go-review.googlesource.com/5221
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
The current XML printer does not understand the xmlns
attribute. This change changes it so that it interprets the
xmlns attributes in the tokens being printed, and uses
appropriate prefixes.
Fixes#7535.
Change-Id: I20fae291d20602d37deb41ed42fab4c9a50ec85d
Reviewed-on: https://go-review.googlesource.com/2660
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Before, an array of size 4 would always be allocated even if a tag
doesn't have any attributes. Now that array is allocated only if
needed.
benchmark old allocs new allocs delta
BenchmarkUnmarshal 191 176 -8.5%
Change-Id: I4d214b228883d0a6e892c0d6eb00dfe2da84c116
Reviewed-on: https://go-review.googlesource.com/4160
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Only documentation / comment changes. Update references to
point to golang.org permalinks or go.googlesource.com/go.
References in historical release notes under doc are left as is.
Change-Id: Icfc14e4998723e2c2d48f9877a91c5abef6794ea
Reviewed-on: https://go-review.googlesource.com/4060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use Fatalf for formatting directive rather than plain Fatal.
Change-Id: Iebd30cd6326890e9501746113a6d97480949e3d2
Reviewed-on: https://go-review.googlesource.com/2161
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The error message for decoding a unquoted value into a struct field with
the ,string option specified has two arguments when one is needed.
Make the error message take one argument and add a test in order to cover
the case when a unquoted value is specified.
Also add error value as the missing argument for Fatalf call in test.
Fixes the following go vet reports:
decode.go:602: wrong number of args for format in Errorf call: 1 needed but 2 args
decode_test.go:1088: missing argument for Fatalf("%v"): format reads arg 1, have only 0 args
Change-Id: Id036e10c54c4a7c1ee9952f6910858ecc2b84134
Reviewed-on: https://go-review.googlesource.com/2109
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
intDataSize ignores unsigned integers, forcing reads/writes to miss the fast path.
Fixes#8956
Change-Id: Ie79b565b037db3c469aa1dc6d0a8a5a9252d5f0a
Reviewed-on: https://go-review.googlesource.com/1777
Reviewed-by: Russ Cox <rsc@golang.org>
Some applications use unpadded base64 format, omitting the trailing
'=' padding characters from the standard base64 format, either to
minimize size or (more justifiably) to avoid use of the '=' character.
Unpadded flavors are standard and documented in section 3.2 of RFC 4648.
To support these unpadded flavors, this change adds two predefined
encoding variables, RawStdEncoding and RawURLEncoding, for unpadded
encodings using the standard and URL character set, respectively.
The change also adds a function WithPadding() to customize the padding
character or disable padding in a custom Encoding.
Finally, I noticed that the existing base64 test-suite was only
exercising the StdEncoding, and not referencing URLEncoding at all.
This change adds test-suite functionality to exercise all four encodings
(the two existing ones and the two new unpadded flavors),
although it still doesn't run *every* test on all four encodings.
Naming: I used the "Raw" prefix because it's more concise than "Unpadded"
and seemed just as expressive, but I have no strong preferences here.
Another short alternative prefix would be "Min" ("minimal" encoding).
Change-Id: Ic0423e02589b39a6b2bb7d0763bd073fd244f469
Reviewed-on: https://go-review.googlesource.com/1511
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is unused. It was introduced in the CL that added InputOffset.
I suspect it was an editing mistake.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/182580043
In theory both of these lines encode the same three fields:
a,,c
a,"",c
However, Postgres defines that when importing CSV, the unquoted
version is treated as NULL (missing), while the quoted version is
treated as a string value (empty string). If the middle field is supposed to
be an integer value, the first line can be imported (NULL is okay), but
the second line cannot (empty string is not).
Postgres's import command (COPY FROM) has an option to force
the unquoted empty to be interpreted as a string but it does not
have an option to force the quoted empty to be interpreted as a NULL.
From http://www.postgresql.org/docs/9.0/static/sql-copy.html:
The CSV format has no standard way to distinguish a NULL
value from an empty string. PostgreSQL's COPY handles this
by quoting. A NULL is output as the NULL parameter string
and is not quoted, while a non-NULL value matching the NULL
parameter string is quoted. For example, with the default
settings, a NULL is written as an unquoted empty string,
while an empty string data value is written with double
quotes (""). Reading values follows similar rules. You can
use FORCE_NOT_NULL to prevent NULL input comparisons for
specific columns.
Therefore printing the unquoted empty is more flexible for
imports into Postgres than printing the quoted empty.
In addition to making the output more useful with Postgres, not
quoting empty strings makes the output smaller and easier to read.
It also matches the behavior of Microsoft Excel and Google Drive.
Since we are here and making concessions for Postgres, handle this
case too (again quoting the Postgres docs):
Because backslash is not a special character in the CSV
format, \., the end-of-data marker, could also appear as a
data value. To avoid any misinterpretation, a \. data value
appearing as a lone entry on a line is automatically quoted
on output, and on input, if quoted, is not interpreted as
the end-of-data marker. If you are loading a file created by
another application that has a single unquoted column and
might have a value of \., you might need to quote that value
in the input file.
Fixes#7586.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/164760043
As we did with encoding, provide a trivial byte reader for
faster decoding. We can also reduce some of the copying
by doing the allocation all at once using a slightly different
interface from byte buffers.
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 13368 12902 -3.49%
BenchmarkEndToEndByteBuffer 5969 5642 -5.48%
BenchmarkEndToEndSliceByteBuffer 479485 470798 -1.81%
BenchmarkEncodeComplex128Slice 92367 92201 -0.18%
BenchmarkEncodeFloat64Slice 39990 38960 -2.58%
BenchmarkEncodeInt32Slice 30510 27938 -8.43%
BenchmarkEncodeStringSlice 33753 33365 -1.15%
BenchmarkDecodeComplex128Slice 232278 196704 -15.32%
BenchmarkDecodeFloat64Slice 150258 128191 -14.69%
BenchmarkDecodeInt32Slice 133806 115748 -13.50%
BenchmarkDecodeStringSlice 335117 300534 -10.32%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/154360049
Bytes buffers have more API and are a little slower. Since appending
is a key part of the path in encode, using a faster implementation
speeds things up measurably.
The couple of positive swings are likely garbage-collection related
since memory allocation looks different in the benchmark now.
I am not concerned by them.
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 6620 6388 -3.50%
BenchmarkEndToEndByteBuffer 3548 3600 +1.47%
BenchmarkEndToEndSliceByteBuffer 336678 367980 +9.30%
BenchmarkEncodeComplex128Slice 78199 71297 -8.83%
BenchmarkEncodeFloat64Slice 37731 32258 -14.51%
BenchmarkEncodeInt32Slice 26780 22977 -14.20%
BenchmarkEncodeStringSlice 35882 26492 -26.17%
BenchmarkDecodeComplex128Slice 194819 185126 -4.98%
BenchmarkDecodeFloat64Slice 120538 120102 -0.36%
BenchmarkDecodeInt32Slice 106442 107275 +0.78%
BenchmarkDecodeStringSlice 272902 269866 -1.11%
LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/160990043
Use go generate to write better loops for decoding arrays,
just as we did for encoding. It doesn't help as much,
relatively speaking, but it's still noticeable.
benchmark old ns/op new ns/op delta
BenchmarkDecodeComplex128Slice 202348 184529 -8.81%
BenchmarkDecodeFloat64Slice 135800 120979 -10.91%
BenchmarkDecodeInt32Slice 121200 105149 -13.24%
BenchmarkDecodeStringSlice 288129 278214 -3.44%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/154420044
