This adds a new type wrapper that decodes as a list, but does not
actually decode the contents of the list. The type parameter exists as a
marker, and enables decoding the elements lazily. RawList can also be
used for building a list incrementally.
Co-authored-by: Felix Lange <fjl@twurst.com>
As of Go 1.19, it is permitted to call Bytes() on a reflect.Value
representing an adressable byte array. So we can remove our workaround,
undoing #22924.
https://go.dev/doc/go1.19#reflectpkgreflect
> The method [Value.Bytes](https://go.dev/pkg/reflect/#Value.Bytes) now
accepts addressable arrays in addition to slices.
Co-authored-by: Felix Lange <fjl@twurst.com>
This adds support for importing types from multiple identically-named
packages.
---------
Co-authored-by: VolodymyrBg <aqdrgg19@gmail.com>
Co-authored-by: Felix Lange <fjl@twurst.com>
The bug can cause crashes if Read is called after EOF has been returned.
No code performs such calls right now, but hitting the bug gets more
likely as rlp.EncodeToReader gets used in more places.
Decoding did not reject byte arrays of length one with a single element
b where 55 < b < 128. Such byte arrays must be rejected because
they must be encoded as the single byte b instead.
The list size checking overflowed if the size information
for a value was bigger than the list. This is resolved by
always performing the check before reading.
The rules have changed as follows:
* When decoding into pointers, empty values no longer produce
a nil pointer. This can be overriden for struct fields using the
struct tag "nil".
* When decoding into structs, the input list must contain an element
for each field.
All integers (including size information in type tags) need to be
encoded using the smallest possible encoding. This commit expands the
stricter validation introduced for *big.Int in commit 59597d23a5
to all integer types and size tags.
A single zero byte carries information and should not set the pointer
to nil. This is arguably a corner case. While here, fix the comment
to explain pointer reuse.
This is a preliminary fix for #420 (SEC-18 RLP decoder unsafe
allocation). If a sane input limit is set on the rlp.Stream,
it should no longer be possible to cause huge []byte allocations.
