Protobuf 3 Enum Deserialization (C++). Cannot distinguish between unset and out of bounds enum field

I am working with protobuf 3.21 in a c++ environment.

When deserializing closed enum values I've found three cases:

enum field is set and valid -> field descriptor hasField returns true
enum field is not set -> hasField returns false, default enum value assumed
enum field was set but value was out of bounds -> hasField returns false, invalid value is written to UnknownFieldSet and field value reset to default enum value

Based on the documentation of enums these seem to work as intended.

But how can one differenciate between the last two cases? I've also tried FieldDescriptor::has_presence() but it returns the same value in both cases. I assumed one would be able to correlate between the entry in the UnknownFieldSet and the actual Field, however based on the documentation this does not seem to be the case, see UnknownField and FieldDescriptor. I understand that protobuf does not differenciate between an enum field being unset and being set to default, but this is a separate case.

So, am I missing/misunderstanding something here or is this simply not possible?

I've read the documentation, tried finding information on Google, GitHub, StackOverflow. I've tried correlating between UnknownField and FieldDescriptor but there don't seem to be fields that allow this.

Solution

I managed to solve the issue. It is in fact possible to differenciate between cases 2 and 3. Fields can be identified by their number. So simply compare the number of the field and check if a field in the UnknownFieldSet has that number. If one such UnknownField could be found we have case 3. If not, case 2.

I did not originally find this approach since last I checked the documentation for fields does not contain a method for retrieving its number since it's implemented as a macro. Also there is no documentation on what the number value even represents. Based on a reddit comment and my own tests it seems to be an index of fields in the message. Either way, I managed to fix the issue this way.