4 ms·

This seems like a great resource. Kudos. > But most of them are based on the incomplete specs from Google's developer site. None of them can correctly predict

This seems like a great resource. Kudos. > But most of them are based on the incomplete specs from Google's developer site. None of them can correctly predict what source files protoc will actually accept or reject 100% of the time. I'd like to think I got pretty close with the plugin that now ships with IntelliJ. It even supports the 65-bit integer literal [1] that protoc happens to accept for proto2-style float and double default values. With this as a starting point, it'd be nice to fix some of the pecularities that arise from "implementation as spec", such as that literal value, and the fact that colon optionality in text format is based on value type, not syntax. 1: https://github.com/jvolkman/intellij-protobuf-editor/blob/6e1f946ef24b19b97a777c7eb0f07d67dcbefb09/core/src/main/java/idea/plugin/protoeditor/lang/psi/ProtoNumberValue.java#L234-L243 https://github.com/jvolkman/intellij-protobuf-editor/blob/6e...

miohtama 4y ago
Out of curiosity, why does Protobuf allow a negative 64-bit value in the first place? No CPU architecture supports such as far as I know.
- kentonv 4y ago
  It's been 15 years since I wrote this so I don't remember exactly, but I think it's just an implementation quirk. See: https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/compiler/parser.cc#L1321 https://github.com/protocolbuffers/protobuf/blob/main/src/go... The parser consumes a "-", then consumes a number. The number can be any 64-bit unsigned integer. It is then converted to a double. Finally, if a "-" was seen earlier, it is negated. So by accident, it ends up allowing the range of a 65-bit signed integer.
- jvolkman 4y ago
  It's just a long-standing quirk in the parser. It parses the numeric part as an unsigned 64-bit number, then applies the sign afterwards. And the result can be approximately stuffed into a floating point value. The behavior for integer fields is different; compilation will fail with an out of range error.

miohtama 4y ago

Out of curiosity, why does Protobuf allow a negative 64-bit value in the first place? No CPU architecture supports such as far as I know.

kentonv 4y ago
It's been 15 years since I wrote this so I don't remember exactly, but I think it's just an implementation quirk. See: https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/compiler/parser.cc#L1321 https://github.com/protocolbuffers/protobuf/blob/main/src/go... The parser consumes a "-", then consumes a number. The number can be any 64-bit unsigned integer. It is then converted to a double. Finally, if a "-" was seen earlier, it is negated. So by accident, it ends up allowing the range of a 65-bit signed integer.
jvolkman 4y ago
It's just a long-standing quirk in the parser. It parses the numeric part as an unsigned 64-bit number, then applies the sign afterwards. And the result can be approximately stuffed into a floating point value. The behavior for integer fields is different; compilation will fail with an out of range error.