require all memory reads to be aligned. Specifically, it turns out that
sizeof(RepeatedField<bool>) is 20 on 64-bit sparc with GCC 3.4.6. This is
strange, since one of RepeatedField's members is a pointer, which I thought
meant that it had to be 64-bit aligned, which means its size should be a
multiple of 64 bits. But, 20 is not a multiple of 8. I don't understand why
this is the case, but if this is possible, then DynamicMessage's strategy of
sorting fields in descending order by size and then tightly packing doesn't
work. To fix this, I got rid of the sort step and instead added code that
aligns each field's offset appropriately based on the field's size.
Also in this revision: Fix an error message that named a flag incorrectly.
Details:
For each message type, protoc generates an array of byte offsets of each of
the fields within the message class. These offsets are later used by the
reflection implementation. Prior to this revision, the offset arrays were
allocated as global variables. Since they were just arrays of ints, they
should have been initialized at compile time. Unfortunately, GCC 4.3.0
incorrectly decides that they cannot be initialized at compile time because
the values used to initialize the array have type ptrdiff_t, and GCC 4.3.0
does not recognize that it can convert ptrdiff_t to int at compile time. This
bug did not seem to exist in previous versions of GCC. Google's compiler
team has submitted a fix for this bug back to the GCC project, but we will
have to work around it anyway since Fedora 9 shipped with GCC 4.3.0.
General
* License changed from Apache 2.0 to New BSD.
* It is now possible to define custom "options", which are basically
annotations which may be placed on definitions in a .proto file.
For example, you might define a field option called "foo" like so:
import "google/protobuf/descriptor.proto"
extend google.protobuf.FieldOptions {
optional string foo = 12345;
}
Then you annotate a field using the "foo" option:
message MyMessage {
optional int32 some_field = 1 [(foo) = "bar"]
}
The value of this option is then visible via the message's
Descriptor:
const FieldDescriptor* field =
MyMessage::descriptor()->FindFieldByName("some_field");
assert(field->options().GetExtension(foo) == "bar");
This feature has been implemented and tested in C++ and Java.
Other languages may or may not need to do extra work to support
custom options, depending on how they construct descriptors.
C++
* Fixed some GCC warnings that only occur when using -pedantic.
* Improved static initialization code, making ordering more
predictable among other things.
* TextFormat will no longer accept messages which contain multiple
instances of a singular field. Previously, the latter instance
would overwrite the former.
* Now works on systems that don't have hash_map.
Python
* Strings now use the "unicode" type rather than the "str" type.
String fields may still be assigned ASCII "str" values; they will
automatically be converted.
* Adding a property to an object representing a repeated field now
raises an exception. For example:
# No longer works (and never should have).
message.some_repeated_field.foo = 1
Python tests run correctly even when a previous version of the library is
already installed. I was unable to reproduce his problem on my machine but
the fix seems harmless enough.
kenton@google.com
Jon Skeet
The Android Open Source Project
temporal