Added comment about using fixed-size objects when data could be passed between different CPU archit…

base/metrics/persistent_memory_allocator.h

 // Copyright (c) 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef BASE_METRICS_PERSISTENT_MEMORY_ALLOCATOR_H_
 #define BASE_METRICS_PERSISTENT_MEMORY_ALLOCATOR_H_
 
 #include <stdint.h>
 
 #include <atomic>
@@ skipping 206 matching lines @@
 
   // Get an object referenced by a |ref|. For safety reasons, the |type_id|
   // code and size-of(|T|) are compared to ensure the reference is valid
   // and cannot return an object outside of the memory segment. A |type_id| of
   // kTypeIdAny (zero) will match any though the size is still checked. NULL is
   // returned if any problem is detected, such as corrupted storage or incorrect
   // parameters. Callers MUST check that the returned value is not-null EVERY
   // TIME before accessing it or risk crashing! Once dereferenced, the pointer
   // is safe to reuse forever.
   //
+  // IMPORTANT: If there is any possibility that this allocator will be shared
+  // across different CPU architectures (perhaps because it is being persisted
+  // to disk), then it is essential that the object be of a fixed size. All
+  // fields must be of a defined type that does not change across CPU architec-
+  // tures or natural word sizes (i.e. 32/64 bit). Acceptable are char and
+  // (u)intXX_t. Unacceptable are int, bool, or wchar_t which are implemen-
+  // tation defined with regards to their size.
+  //
+  // ALSO: Alignment must be consistent. A uint64_t after a uint32_t will pad
+  // differently between 32 and 64 bit architectures. Either put the bigger
+  // elements first, group smaller elements into blocks the size of larger
+  // elements, or manually insert padding fields as appropriate.
+  //
   // NOTE: Though this method will guarantee that an object of the specified
   // type can be accessed without going outside the bounds of the memory
   // segment, it makes no guarantees of the validity of the data within the
   // object itself. If it is expected that the contents of the segment could
   // be compromised with malicious intent, the object must be hardened as well.
   //
   // Though the persistent data may be "volatile" if it is shared with
   // other processes, such is not necessarily the case. The internal
   // "volatile" designation is discarded so as to not propagate the viral
   // nature of that keyword to the caller. It can add it back, if necessary,
@@ skipping 222 matching lines @@
  private:
   std::unique_ptr<MemoryMappedFile> mapped_file_;
 
   DISALLOW_COPY_AND_ASSIGN(FilePersistentMemoryAllocator);
 };
 #endif  // !defined(OS_NACL)
 
 }  // namespace base
 
 #endif  // BASE_METRICS_PERSISTENT_MEMORY_ALLOCATOR_H_