This PR addresses a `index out of range` panic in `parseGNUStepValue`.
This panic was identified as part of internal fuzzer based testing of
our code.

Reproducer
```go
package main

import (
	"bytes"

	"howett.net/plist"
)

func main() {
	data := []byte(`(plist versionGetValue<*B"">`)

	dec := plist.NewDecoder(bytes.NewReader(data))
	res := make(map[string]interface{})

	_ = dec.Decode(res)
}
```

Results

```shell
go run ./main.go

panic: runtime error: index out of range [0] with length 0 [recovered]
	panic: runtime error: index out of range [0] with length 0 [recovered]
	panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
howett.net/plist.(*Decoder).Decode.func1()
	/Users/me/git/go-plist/decode.go:30 +0xac
panic({0x1023deaa0?, 0x14000116018?})
	/usr/local/go/src/runtime/panic.go:914 +0x218
howett.net/plist.(*textPlistParser).parseDocument.func1()
	/Users/me/git/go-plist/text_parser.go:74 +0xe0
panic({0x1023deaa0?, 0x14000116018?})
	/usr/local/go/src/runtime/panic.go:914 +0x218
howett.net/plist.(*textPlistParser).parseGNUStepValue(0x1400010aea0)
	/Users/me/git/go-plist/text_parser.go:460 +0x4e0
howett.net/plist.(*textPlistParser).parsePlistValue(0x1400010aea0)
	/Users/me/git/go-plist/text_parser.go:554 +0x17c
howett.net/plist.(*textPlistParser).parseArray(0x1400010aea0)
	/Users/me/git/go-plist/text_parser.go:399 +0xd4
howett.net/plist.(*textPlistParser).parsePlistValue(0x1400010aea0)
	/Users/me/git/go-plist/text_parser.go:567 +0x190
howett.net/plist.(*textPlistParser).parseDocument(0x1400010aea0)
	/Users/me/git/go-plist/text_parser.go:91 +0xa4
howett.net/plist.(*Decoder).Decode(0x14000140000, {0x1023d21e0, 0x140001101b0})
	/Users/me/git/go-plist/decode.go:58 +0x210
main.main()
	/Users/me/git/go-plist/cmd/crasher/main.go:15 +0xfc
exit status 2
```

I built a quick Fuzzer for `Decode` with a good test corpus in order to
identify related bugs but nothing shook out in roughly an hour. 

This is only a partial fix which works for the value of 3 and for any
value < 8, but won't help in other cases. Supporting values < 16 should
also be possible, but I didn't bother with it. Also this doesn't touch
`bplist_generator` and hence won't make use of non-standard values for
generating plists (while those values could probably give a benefit of
slightly reduced plist size).

We confirmed that this is supported by the CoreFoundation bplist parser.

Closes #77

Graham Miln authored Oct 21, 2022 and Dustin L. Howett committed Nov 02, 2022

Expand interface check beyond the immediate type of the value. This
allows for custom marshaling of structures with interface and indirect
field types.

Closes #72

Received a "error parsing text property list: missing ; in dictionary .." error
when opening an Xcode project saved encoded by the package.
Found the root cause to be a dictionary value containing an apostrophe, e.g. "JSON's".
Added this character to the bitmap containing quotable chars.

Fixes https://github.com/DHowett/go-plist/issues/65.

This commit also adds a benchmark for array unmarshaling. The difference
is staggering.

name                   old time/op    new time/op    delta
LargeArrayUnmarshal-4    23.4µs ± 2%     0.4µs ± 2%  -98.49%  (p=0.000 n=9+9)

name                   old alloc/op   new alloc/op   delta
LargeArrayUnmarshal-4     96.0B ± 0%    128.0B ± 0%  +33.33%  (p=0.000 n=10+10)

name                   old allocs/op  new allocs/op  delta
LargeArrayUnmarshal-4      3.00 ± 0%      4.00 ± 0%  +33.33%  (p=0.000 n=10+10)

Fixes https://github.com/DHowett/go-plist/issues/61

`go test -tags dump` will produce a directory containing all of plist's
test collateral.

GNUStep is very lax when it comes to parsing these. Closing quotes
aren't required (as pointed out by @Artoria2e5, and held up by empirical
validation), so all we need to do is strip a closing " even if we don't
detect an opening one.

This commit also fleshes out the invalid test cases for <* and reworks
some of the error-handling logic to make the errors clearer.  Type
checks have been lifted up to the head of the ext. val. parser and the
emptiness check has been tidied up a bit.

Co-authored-by: Mingye Wang <arthur200126@gmail.com>

Closes https://github.com/DHowett/go-plist/pull/51.

Mingye Wang authored Apr 19, 2020 and Dustin L. Howett committed Apr 19, 2020

GNUStep parses <[xxx]> as a base64-encoded NSData using
NSDataBase64DecodingIgnoreUnknownCharacters. It's fairly robust.

Co-authored-by: Dustin L. Howett <dustin@howett.net>

Coauthor notes:
I elevated the base64 string Map filter to a tabled character set and
added characterSet.Map() so that it could plug into strings.Map.

I've also gone ahead and added some failure case tests and a couple
extra tests for data that doesn't contain base64 characters.

References https://github.com/DHowett/go-plist/pull/51.

Squashed commit of the following (from Mingye)

commit 767da5373da65ab45885d84aa4cec6f3a8d65f0c
    Add test case for GNUstep base64 parsing
commit 748f6fc4e0afe16daa34534b7b02ca61676355b6
    Update text_parser.go: lowercase strings
commit 9d912f71f6e86967e2a110db789c8e43b152997c
    text_parser: add gnustep base64 parsing

Right now, it only runs for Go 1.13.

Although Apple's NSKeyedArchiver does not want to encode to things that are neither XML nor binary, GNUstep's version has no such limitation. On GNUstep they do what Apple does for XML for the text format too.

The proposed change consolidates the packing into one place.

Closes https://github.com/DHowett/go-plist/issues/53.

[skip ci]

This change introduces a difference in parsing from the reference
parser: the reference parser will always choose the _first_ value seen
associated with a key, while we will always choose the _last_.

This is not regarded as a compatibility issue, as there is no way to
provide a useful and re-serializable value in the presence of duplicate
keys.

Fixes https://github.com/DHowett/go-plist/issues/37.

This commit intoduces a mostly hand-rolled XML encoder inspired by
xml.Encoder. Since plist is a simple format that doesn't require
attributes, only has one data type with encodeable input and is
otherwise constrained, we don't need the full power of encoding/xml.

The encoder's speed, memory requirements and number of allocations are
all improved.

In addition, we can now emit self-closing tags for empty elements
(<key></key> -> <key/>).

Fixes https://github.com/DHowett/go-plist/issues/34.

name                    old time/op    new time/op    delta
XMLEncode-4               25.9µs ± 3%    14.9µs ± 1%   -42.66%
BigXMLGenerate-4          47.3ms ± 1%    23.7ms ± 1%   -49.91%
BigPrettyXMLGenerate-4    55.0ms ± 1%    30.0ms ± 1%   -45.42%
XMLGenerate-4             16.0µs ± 1%     5.8µs ± 1%   -63.81%

name                    old alloc/op   new alloc/op   delta
XMLEncode-4               8.71kB ± 0%    6.42kB ± 0%   -26.26%
BigXMLGenerate-4          2.62MB ± 0%    1.60MB ± 0%   -39.02%
BigPrettyXMLGenerate-4    2.62MB ± 0%    1.60MB ± 0%   -39.02%
XMLGenerate-4             5.83kB ± 0%    4.50kB ± 0%   -22.77%

name                    old allocs/op  new allocs/op  delta
XMLEncode-4                 88.0 ± 0%      63.0 ± 0%   -28.41%
BigXMLGenerate-4           86.7k ± 0%     72.6k ± 0%   -16.24%
BigPrettyXMLGenerate-4     86.7k ± 0%     72.6k ± 0%   -16.24%
XMLGenerate-4               54.0 ± 0%      31.0 ± 0%   -42.59%

A number of our hand-crafted binary plists had a sortVersion > 0x00,
and the "strange characters" text tests were hex-encoded for some
reason.

This fixes a long-standing bug where we would serialize unsigned 64-bit
integers >= 0x8000000000000000 in violation of the bplist00 spec. The
spec tells us that _all_ 64-bit values are signed. Those high-half
64-bit integers are meant to be stored as signed 128-bit integers with a
high half of 0x0000000000000000.

Tests have been updated to reflect this.

This commit builds on @gumpyoung's work in
https://github.com/DHowett/go-plist/pull/35.

Fixes https://github.com/DHowett/go-plist/issues/36.
Fixes https://gitlab.howett.net/DHowett/plist/issues/32.

Refs #22.

This commit moves all of the text tests into the common tests, the
invalid tests out of the common tests (since the test fixtures had to
have a lot of logic to handle "expected fail" tests, and it wasn't a
good idea anyway), and moves all formats into their own subtests.

TestData's members have been renamed to make them less naive.