Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RLP decoding woes #77

Closed
holiman opened this issue Jun 5, 2020 · 4 comments
Closed

RLP decoding woes #77

holiman opened this issue Jun 5, 2020 · 4 comments

Comments

@holiman
Copy link
Owner

holiman commented Jun 5, 2020

We now have rlp encoding, and can encode RLP. However, RLP decoding requires to implement this interface: https://github.com/ethereum/go-ethereum/blob/44b41641f8220fe79e43461356c147cc3cc72380/rlp/decode.go#L64

I.e,

type Decoder interface {
	DecodeRLP(*Stream) error
}

Where *Stream is this struct from the same package.

If we want uint256.Int to implement that, it would require adding rlp as a dependency :( .

@fjl any ideas to get us out of this? Seems quirky, from API-perspective, to have Encoder interface be implementable without rlp-dependency, but have the Decoder interface depend on package rlp.

@fjl
Copy link

fjl commented Jun 8, 2020

The Decoder taking stream is an unfortunate design decision, but it does make the decoder work a bit faster because you have direct access to the underlying parser state in your custom decoder.

@holiman
Copy link
Owner Author

holiman commented Jun 8, 2020

Yeah.. I'm thinking that maybe we'll add DecodeRLPBytes([]byte) error, and then the a 'custom' decoder can just do a.DecodeRLPBytes(stream.Bytes()).

@holiman
Copy link
Owner Author

holiman commented Jun 8, 2020

I was thinking something like this:

func (z *Int) DecodeRLPBytes(b []byte) error {
	// Check length
	if len(b) > 32 {
		return errors.New("rlp: uint overflow")
	}
	if len(b) == 0 {
		z.Clear()
		return nil
	}
	// Check leading zero-bytes
	if b[0] == 0 {
		return errors.New("rlp: non-canonical integer format")
	}
	z.SetBytes(b)
}

But I don't know -- perhaps not worth it, since we will have to have a custom uint256-decoder inside rlp anyway.

@fjl
Copy link

fjl commented Jun 8, 2020

I think we can agree to just add special support for uint256 in package rlp.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants