Serialized signture improvements #658
Conversation
These functions always return the same value so are not useful and actually calling them is a red flag.
These traits were missing and could be useful if e.g. one wants to store serialized signatures in a set/map and access them using `[u8]`.
Converting signature to serialized signature and back is natural, so the conversion traits should be implemented.
Kixunil
force-pushed
the
serialized-signture-improvements
branch
from
4c845c7 to
62c839c
Compare
| @@ -84,6 +127,7 @@ impl SerializedSignature { | |||
| } | |||
|
|
|||
| /// Get the capacity of the underlying data buffer. | |||
| #[deprecated = "This always returns 72"] | |||
There was a problem hiding this comment.
If this is true why is the buffer size const called MAX_LEN? Also, if it is always 72 why do we even have the len field?
There was a problem hiding this comment.
FTR I didn't look up the rules of sigs right now, and I don't knew them off the top of my head, I'm just looking at the code.
There was a problem hiding this comment.
This is related to #659, reviewing that PR made me wonder why we do equality/ord comparison on the bytes not covered by the len field.
There was a problem hiding this comment.
Don't confuse self.data.len() (which is MAX_LEN because of array) with self.len :)
why we do equality/ord comparison on the bytes not covered by the
lenfield.
I'm not sure what you mean. The array only contains valid data up to len so we compare only those. The rest may be considered padding. (If we wanted to be crazy efficient we would use MaybeUninit<u8> instead.)
There was a problem hiding this comment.
Ignore me, I don't know what code I was looking at yesterday, the **self == **other seemed totally new to me just now, I was baffled for a minute till I saw the Deref impl.
This deprecates methods returning constants and impls a few traits.