C++: narrowing conversion warnings (64-bit ptrdiff_t to 32-bit int) in 'google/protobuf/repeated_field.h' in pointer arithmetics

[antrv]

What version of protobuf and what language are you using?
Version: main
Language: C++

What operating system (Linux, Windows, ...) and version?
Windows 64-bit

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

A lot of warning in pointer arithmetics on 64-bit platform because of ptrdiff_t (64-bit) to int (32-bit) narrowing conversion in google/protobuf/repeated_field.h.

Possibly size field of RepeatedField class must be of type size_t instead of int.

[hartwork]

@antrv my vote for sharing the relevant parts of the compiler output in some form.

CC #20373

[antrv]

I'm sorry. Here is some compiler output:

<part of path removed>\include\google\protobuf\repeated_field.h(921,20): warning C4244: '=': conversion from '__int64' to 'int', possible loss of data [<file path removed>]
  (compiling source file '<file path removed>')
      <part of path removed>\include\google\protobuf\repeated_field.h(921,20):
      the template instantiation context (the oldest one first) is
          <file path removed>(77,25):
          see reference to function template instantiation '<function signature removed>' being compiled
          with
          [
              Event=<removed>
          ]
          <file path removed>(134,35):
          see reference to function template instantiation '<function signature removed>' being compiled
          with
          [
              Event=<removed>
          ]
          <file path removed>(70,43):
          see reference to function template instantiation 'google::protobuf::RepeatedField<int>::RepeatedField<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<_Ty>>>,void>(Iter,Iter)' being compiled
          with
          [
              _Ty=int,
              Iter=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>
          ]
          <part of path removed>\include\google\protobuf\repeated_field.h(676,3):
          see reference to function template instantiation 'void google::protobuf::RepeatedField<int>::Add<Iter>(Iter,Iter)' being compiled
          with
          [
              Iter=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>
          ]
          <part of path removed>\include\google\protobuf\repeated_field.h(947,5):
          see reference to function template instantiation 'void google::protobuf::RepeatedField<int>::AddInputIterator<Iter>(Iter,Iter)' being compiled
          with
          [
              Iter=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>
          ]
  
<part of path removed>\include\google\protobuf\repeated_field.h(934,30): warning C4244: 'initializing': conversion from '__int64' to 'int', possible loss of data [<file path removed>]
  (compiling source file '<file path removed>')
  
<part of path removed>\include\google\protobuf\repeated_field.h(934,22): warning C4244: 'initializing': conversion from '__int64' to 'const int', possible loss of data [<file path removed>]
  (compiling source file '<file path removed>')

Line number are slightly different in the main branch, but the problematic code is still there I verified. The warnings are about assigning pointer difference to the variable of type int. The problematic code looks like this:

      size = first - elem;

or

  const int new_size = first - elem;

where first and elem are pointers.

[acozzette]

I would be happy to review any pull requests that fix these warnings. However, I think we would probably need to avoid doing anything that increases the size of RepeatedField (or RepeatedPtrField), since that could cause problems for messages with large numbers of repeated fields.

[hartwork]

@acozzette I'm reading that as "adding explicit casts (as a silencer) and pre-cast assertions that all the lost bits are zero (to reduce attack impact to denial of service) is the only way forward" (which would likely not be a complete fix). Could you clarify?

[acozzette]

I don't have a particular fix in mind and haven't looked at the problem very carefully yet. I just suspect that increasing the size of RepeatedField would likely cause problems.