When unmarshaling an array from a plist file into a slice, two issues
occur related to slice capacity growth:

- Unnecessary growth: The slice grows even when the current capacity is
  enough to hold all elements. Specifically, the slice grows
  `if cnt >= val.Cap()`, even when the current capacity is sufficient.
- Doubling capacity: The slice's capacity is always doubled, which is
  inefficient. It should follow a more dynamic growth pattern, similar
  to Go's built-in slice growth algorithm.

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

We do not support unmarshaling dictionaries into maps with a non-string
key type. We currently panic with an error from within the reflect
package.

This commit introduces a more specific error to cover this case, plus
tests to confirm that we can still unmarshal into aliased string types.

Fixes https://github.com/DHowett/go-plist/issues/44
Refs https://github.com/DHowett/go-plist/issues/85

Graham Miln authored Dec 26, 2024 and Dustin L. Howett committed Dec 26, 2024

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

Graham Miln authored Dec 26, 2024 and Dustin L. Howett committed Dec 26, 2024

Support unmarshal of dates to types implementing the Unmarshaler interface.

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

Embedded struct fields are recorded in `fieldInfo` by taking the outer
structure's field indices and concatenating the field indices for every
field inside the embedded one.

Given the example structs,

```go
struct Outer {
        S string
        *Inner   `plist:",omitempty"`
}

struct Inner {
        S2 string
}
```

We record the indices...

```
Outer.S  at [0]
Outer.S2 at [1, 0] // Outer.Inner in index 1, Inner.S2 at 0
```

Because we elided the `typeInfo` for `Outer.Inner`, there was nowhere to
store its `omitempty`. We would not want to propagate `omitempty` down
to every child, because that would not represent reality.

This commit introduces tracking for each index in the index path whether
omitempty was set at that level.

Now we understand `Outer.S2` like this:

```
             + Omit if Outer.Inner is empty
             |
Outer.S2 at [1, 0]
```

I chose to use a 64-bit bitfield to record index indices, so if you nest
64 anonymous embedded structs plist will forget the innermost omitempty
flags.

To accomplish this with minimal changes, I split `fieldInfo.value` into
`value` and `valueForWriting`. `value` no longer populates nil pointers
and interfaces, and is safe for reading. `valueForWriting` doesn't care
about `omitempty`, and does populate nil pointers in the destination.

Unfortunately, plist will still populate empty structures for nested
anonymous `omitempty` pointers-to-structs during unmarshal.

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

Working on #82, I realized that this is probably a case we should
support. Testing encoding/json confirmed that.

The marshaler uses the `innermostValue` helper introduced in the last
commit; the unmarshaler just iterates and creates successive new nested
elements until it's out of pointer types.

Previously, we would ignore an interface{} containing a *time.Time and
treat it as a TextMarshaler.

Fixes #82

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.