1. 29 Jul, 2015 1 commit
  2. 28 Apr, 2015 5 commits
    • Charles Munger's avatar
      Throw OutOfSpaceException instead of IllegalArgumentException. · 6732dd7e
      Charles Munger authored
      When a MessageNano containing a String is serialized into a buffer that
      is too small to contain it, and the buffer's boundary happens to be
      where the string field's length delimiting varint is serialized,
      and the string's length and 3*length have the same length when
      encoded as a varint, an IllegalArgumentException is thrown rather than
      an OutOfSpaceException.
      
      Github issue: https://github.com/google/protobuf/issues/292
      
      Change-Id: If478d68cf15bfd0662252d008e42b2bf1ff1c75e
      6732dd7e
    • Brian Duff's avatar
      Add clone() method support for nano. · d099a886
      Brian Duff authored
      Upstreamed from Another Place (cr/57247854).
      
      Change-Id: I2aaf59544c0f5ae21a51891d8a5eeda1dc722c90
      d099a886
    • Brian Duff's avatar
      When no clear() is generated, still initialize fields. · fb96026b
      Brian Duff authored
      https://android-review.googlesource.com/#/c/67890/ removed field
      initialization from the ctor, making it just call clear() instead.
      
      When I added the generate_clear option back (as part of the reftypes
      compat mode) in https://android-review.googlesource.com/#/c/109530/,
      I forgot to ensure that what clear() used to do was inlined in the
      constructor.
      
      This change fixes NPEs that are happening for users of
      reftypes_compat_mode who rely on unset repeated fields being empty
      arrays rather than null.
      
      Change-Id: Idb58746c60f4a4054b7ebb5c3b0e76b16ff88184
      fb96026b
    • Charles Munger's avatar
      Optimize measurement and serialization of nano protos. · 54511f70
      Charles Munger authored
      Measuring the serialized size of nano protos is now a zero-alloc operation, and serializing a proto now allocates no memory (other than the output buffer) instead of O(total length of strings).
      
      Change-Id: Id5e2ac3bdc4ac56c0bf13d725472da3a00c9baec
      Signed-off-by: 's avatarCharles Munger <clm@google.com>
      54511f70
    • Brian Duff's avatar
      Fix bug with large extension field numbers. · ec2f2445
      Brian Duff authored
      Previously, extensions with field numbers greater than 268435455 would
      result in a compile time error in generated code that looks something
      like this:
      
      Foo.java:3178: error: integer number too large: 3346754610
                      3346754610);
      
      This is because we were trying to represent the tag number (an
      unsigned int) using a java int constant, but java int constants are
      signed, and can't exceed Integer.MAX_VALUE.
      
      Fixed by declaring it as a long instead, and casting it down to an
      int in the implementation. This is safe, because the tag value always
      fits in 32 bis.
      
      Change-Id: If2017bacb4e20af667eaeaf9b65ddc2c30a7709f
      ec2f2445
  3. 02 Apr, 2015 1 commit
  4. 20 Feb, 2015 8 commits
  5. 19 Feb, 2015 1 commit
  6. 06 Feb, 2015 2 commits
  7. 05 Feb, 2015 4 commits
  8. 04 Feb, 2015 1 commit
  9. 02 Feb, 2015 2 commits
  10. 27 Nov, 2014 1 commit
  11. 19 Nov, 2014 1 commit