-Wnull dereference warning, when using -Os, -DNDEBUG and -Wnull-dereference flags after upgrading to protobuf 27.4

[dekiertanna]

What version of protobuf and what language are you using? Version: protobuflib: 5.27.4; protoc 27.4 (protobuf lite) Language: C++

What operating system (Linux, Windows, ...) and version? Linux, Red Hat Enterprise Linux Server 7.9 (Maipo)

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

What did you do? Steps to reproduce the behavior: Minimal reproduction included in attached files.

protobuf_lite_minimal_reproduction.zip

Generally, passing an rvalue (temporary value):

    TestMessage message;
    message.add_ids(std::string("test"));

causes

[ 50%] Building CXX object CMakeFiles/MyExecutable.dir/main.o In file included from /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/c++/12.2.0/string:53, from /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/c++/12.2.0/bits/locale_classes.h:40, from /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/c++/12.2.0/bits/ios_base.h:41, from /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/c++/12.2.0/ios:42, from /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/c++/12.2.0/ostream:38, from /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/c++/12.2.0/iostream:39, from /var/fpwork/dekiert/protobuf_reproduction/main.cpp:1: In member function ‘std::cxx11::basic_string<_CharT, _Traits, _Alloc>::pointer std::cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_data() const [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’, inlined from ‘bool std::cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_is_local() const [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/c++/12.2.0/bits/basic_string.h:274:23, inlined from ‘std::cxx11::basic_string<_CharT, _Traits, _Alloc>& std::cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(std::cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/c++/12.2.0/bits/basic_string.h:847:18, inlined from ‘void google::protobuf::internal::RepeatedPtrFieldBase::Add(Value&&) [with TypeHandler = google::protobuf::internal::GenericTypeHandler<std::cxx11::basic_string >; typename std::enable_if::type* = 0]’ at /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/google/protobuf/repeated_ptr_field.h:197:78, inlined from ‘void google::protobuf::RepeatedPtrField::Add(Element&&) [with Element = std::cxx11::basic_string]’ at /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/google/protobuf/repeated_ptr_field.h:1340:41, inlined from ‘void TestMessage::add_ids(std::string&&)’ at /var/fpwork/dekiert/protobuf_reproduction/build/generated/test.pb.h:308:31, inlined from ‘int main()’ at /var/fpwork/dekiert/protobuf_reproduction/main.cpp:7:20: /var/fpwork/dekiert/lim/workspace_protobuf/sdk/tmp/sysroots/qemux86-64/usr/include/c++/12.2.0/bits/basic_string.h:234:28: error: null pointer dereference [-Werror=null-dereference] 234 | { return _M_dataplus._M_p; }

What did you expect to see Compiled code

What did you see instead? Suspicious -Wnull-dereference error

Anything else we should know about your project / environment This issue was not happening on 24.4 version, started occurring after upgrading to protobuf 27.4

[acozzette]

Thank you for the bug report. I find that if I build with that error enabled on gcc I see quite a few errors:

CC=/usr/bin/gcc CXX=/usr/bin/g++ bazel build -k //src/... -c opt --copt=-Werror=null-dereference --copt=-Wno-deprecated-declarations

However, I don't think these are necessarily real bugs. These look like false positives to me. I don't think we can prioritize working on actively making these errors go away, but we would be happy to review pull requests if you can figure out a way to do it.