protocolbuffers / protobuf

Protocol Buffers - Google's data interchange format
http://protobuf.dev
Other
65.65k stars 15.49k forks source link

C++: Enum field named NULL breaks in generated C++ code #6609

Open ivucica opened 5 years ago

ivucica commented 5 years ago

What version of protobuf and what language are you using? Version: $ protoc --version # libprotoc 3.6.1

Language: C++

What operating system (Linux, Windows, ...) and version? Debian stretch

What runtime / compiler are you using (e.g., python version or gcc version) gcc 6.4.0

What did you do? Steps to reproduce the behavior:

  1. Have an enum in an annotation proto message containing a field named NULL.

    https://github.com/grpc-ecosystem/grpc-gateway/blob/3ad0fb96ecfdf73fa2eddb3de116ae98360dbb35/protoc-gen-swagger/options/openapiv2.proto#L218

  2. Use protoc --cpp_out=....... with the proto file.

  3. Attempt to compile the resulting output file g++ -C -o tmp.o protoc-gen-swagger/options/openapiv2.pb.cc

What did you expect to see No errors building.

What did you see instead? Due to a conflict with #define NULL __null somewhere in the compiler or standard headers, the compiler is not happy:

In file included from /usr/include/x86_64-linux-gnu/bits/types/stack_t.h:23:0,
                 from /usr/include/signal.h:303,
                 from /usr/include/x86_64-linux-gnu/sys/param.h:28,
                 from /usr/include/google/protobuf/stubs/port.h:64,
                 from /usr/include/google/protobuf/stubs/common.h:46,
                 from ../../../protoc-gen-swagger/options/openapiv2.pb.h:9,
                 from ../../../protoc-gen-swagger/options/openapiv2.pb.cc:4:
../../../protoc-gen-swagger/options/openapiv2.pb.h:1845:38: error: expected unqualified-id before ‘__null’
   static const JSONSchemaSimpleTypes NULL =
                                      ^
../../../protoc-gen-swagger/options/openapiv2.pb.cc:927:52: error: expected unqualified-id before ‘__null’
 const JSONSchema_JSONSchemaSimpleTypes JSONSchema::NULL;
                                                    ^

Anything else we should know about your project / environment As enum fields named NULL were seemingly broken until now, I propose renaming them just before the code is generated. This does not seem to have been an issue in other languages, and I don't believe this is forbidden by either proto2 or proto3 syntax.

This was reported in https://github.com/grpc-ecosystem/grpc-gateway/issues/1031 -- the annotations there are used in generating OpenAPI v2 ("swagger") JSON description of the .proto-defined API. We can perhaps work around this, but this is still an issue in protoc generator for C++.

keith-bennett-airmap commented 1 year ago

I also hit this issue today. Is there an easy workaround?

github-actions[bot] commented 7 months ago

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

ivucica commented 7 months ago

While I have not tested this recently, presumably it has not been addressed and this indeed should remain active, and enum fields named NULL should be renamed by protoc to something else in C++ code. Same as should be for other language-specific keywords.

maxime1992 commented 6 months ago

Seems to be the same for VOID. We've got an enum to mark an invoice as VOID and this breaks the compilation too.

github-actions[bot] commented 3 months ago

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.

ivucica commented 3 months ago

This issue should not be closed.

Message ID: @.***>

github-actions[bot] commented 1 week ago

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.

maxime1992 commented 6 days ago

This issue should not be closed.