good morning!!!!

Skip to content
Snippets Groups Projects
  1. Nov 25, 2020
  2. Jul 06, 2020
  3. Sep 13, 2019
    • Felix Lange's avatar
      rlp: improve nil pointer handling (#20064) · 96fb8391
      Felix Lange authored
      * rlp: improve nil pointer handling
      
      In both encoder and decoder, the rules for encoding nil pointers were a
      bit hard to understand, and didn't leave much choice. Since RLP allows
      two empty values (empty list, empty string), any protocol built on RLP
      must choose either of these values to represent the null value in a
      certain context.
      
      This change adds choice in the form of two new struct tags, "nilString"
      and "nilList". These can be used to specify how a nil pointer value is
      encoded. The "nil" tag still exists, but its implementation is now
      explicit and defines exactly how nil pointers are handled in a single
      place.
      
      Another important change in this commit is how nil pointers and the
      Encoder interface interact. The EncodeRLP method was previously called
      even on nil values, which was supposed to give users a choice of how
      their value would be handled when nil. It turns out this is a stupid
      idea. If you create a network protocol containing an object defined in
      another package, it's better to be able to say that the object should be
      a list or string when nil in the definition of the protocol message
      rather than defining the encoding of nil on the object itself.
      
      As of this commit, the encoding rules for pointers now take precedence
      over the Encoder interface rule. I think the "nil" tag will work fine
      for most cases. For special kinds of objects which are a struct in Go
      but strings in RLP, code using the object can specify the desired
      encoding of nil using the "nilString" and "nilList" tags.
      
      * rlp: propagate struct field type errors
      
      If a struct contained fields of undecodable type, the encoder and
      decoder would panic instead of returning an error. Fix this by
      propagating type errors in makeStruct{Writer,Decoder} and add a test.
      96fb8391
  4. May 14, 2019
    • Felix Lange's avatar
      rlp: fixes for two corner cases and documentation (#19527) · 8deec2e4
      Felix Lange authored
      These changes fix two corner cases related to internal handling of types
      in package rlp: The "tail" struct tag can only be applied to the last field.
      The check for this was wrong and didn't allow for private fields after the
      field with the tag. Unsupported types (e.g. structs containing int) which
      implement either the Encoder or Decoder interface but not both 
      couldn't be encoded/decoded.
      
      Also fixes #19367
      8deec2e4
  5. Mar 07, 2017
  6. Feb 19, 2016
  7. Sep 10, 2015
  8. Aug 13, 2015
  9. Jul 23, 2015
  10. Jul 22, 2015
  11. Jul 07, 2015
  12. Jun 29, 2015
  13. Mar 25, 2015
  14. Mar 19, 2015
  15. Mar 17, 2015
  16. Feb 11, 2015
  17. Feb 05, 2015
  18. Jan 15, 2015
    • Felix Lange's avatar
      rlp: allow encoding non-empty interface values · fc92abec
      Felix Lange authored
      This needs to be supported because []someInterface does occur sometimes.
      
      Funny enough, the fix involves changes to the decoder. makeDecoder
      cannot return an error for non-empty interfaces anymore because the type
      cache builds both decoder and writer. Do the check at 'runtime' instead.
      fc92abec
    • Felix Lange's avatar
      rlp: add functions for encoding · 552f5b26
      Felix Lange authored
      I'm reasonably confident that the encoding matches the output of
      ethutil.Encode for values that it supports. Some of the tests have been
      adpated from the Ethereum testing repository.
      
      There are still TODOs in the code.
      552f5b26
Loading