Serialization/Deserialization Problem.

[chaosape]

Consider the serialization and deserialization code generated by LmcpGen:

   void MissionCommand::pack(avtas::lmcp::ByteBuffer & buf) const
   {
      // Call parent's pack method
      afrl::cmasi::VehicleActionCommand::pack(buf);
      // Copy the class into the buffer
      buf.putUShort( static_cast<uint16_t>(__WaypointList.size()));
      for (size_t i=0; i<__WaypointList.size(); i++)
      {
         avtas::lmcp::Factory::putObject( (avtas::lmcp::Object*) __WaypointList[i], buf);
      }
      buf.putLong(__FirstWaypoint);

   }
   
   void MissionCommand::unpack(avtas::lmcp::ByteBuffer & buf)
   {
      // Call parent's unpack method
      afrl::cmasi::VehicleActionCommand::unpack(buf);
      // Copy the buffer into the class
      for (size_t i=0; i<__WaypointList.size(); i++)
      {
         if (__WaypointList[i] != nullptr)
            delete __WaypointList[i];
      }
      __WaypointList.clear();
      uint16_t __WaypointList_length = buf.getUShort();
      for (uint32_t i=0; i< __WaypointList_length; i++)
      {
         if (buf.getBool())
         {
            int64_t series_id = buf.getLong();
            uint32_t msgtype = buf.getUInt();
            uint16_t version = buf.getUShort();
            afrl::cmasi::Waypoint* e = (afrl::cmasi::Waypoint*) avtas::lmcp::Factory::createObject( series_id, msgtype, version );
            if ( e != nullptr) e->unpack(buf); 
            __WaypointList.push_back(e);
         }
      }
      __FirstWaypoint = buf.getLong();
   }

Suppose our waypoint vector has 65537 waypoints. During serialization, the pack method will write a short indicating that there is only 1 waypoint but may go one to write many more waypoints than this. size_t's definition is something that is architecture dependent and is often, though not always, identical to the word size.

Now consider what can happen when deserializing such data when sizeof(size_t)>16, we will read the short indicating there is only 1 waypoint, read 1 waypoint, then read an int64_t that we will interpret as the starting waypoint id. However, this starting waypoint will, in actuality, be the first 64 bits of the next waypoint. I think this will actually correspond to the latitude stored as a double. Regardless, this seems like behavior one should try to avoid.