Add support for loading pak files from arbitrary file regions.

base/files/file.h

 // Copyright (c) 2012 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_FILES_FILE_H_
 #define BASE_FILES_FILE_H_
 
 #include "build/build_config.h"
 #if defined(OS_WIN)
 #include <windows.h>
@@ skipping 137 matching lines @@
     // The last modified time of a file.
     base::Time last_modified;
 
     // The last accessed time of a file.
     base::Time last_accessed;
 
     // The creation time of a file.
     base::Time creation_time;
   };
 
+  // Used to hold information about a region [offset + size] of a file.
+  struct BASE_EXPORT Region {
+    static Region WholeFile();

[Jeffrey Yasskin, 2014/07/22 21:22:29]

Maybe-dumb drive-by suggestion: Maybe make this Region::AllOf(const File&) and
use File::GetLength() to fill in the accurate size. Then the implementation of
MemoryMappedFile wouldn't need to include its own size-determination.

[Primiano Tucci (use gerrit), 2014/07/23 23:17:38]

If you take a look to patchsets 3-4 I used that approach there, then switched to
kWholeFile. Why?
The reason is mostly this: I want to make sure that my change is a noop for the
remaining existing chromium code (i.e. all the code paths that today do a mmap)
w.r.t of the arguments passed to MapViewOfFile.
In other words, if I do as you suggest, in mapped_file_win.cc, all the existing
code paths would end-up calling MapViewOfFile(...size=ActualFileSize...).
Instead, what happens today (for whole file mapping) is
MapViewOfFile(...size=0...), where size=0 has the special semantic, in the
WinAPI, of mapping the entire file.

Now, from a logic viewpoint, providing the size ourselves or asking windows to
calculate it for us *should* be equivalent. On the other side I don't have
enough WinAPI expertise to be 100% sure that the two aforementioned patterns (
map(size=0) and map (size=actual_size)) will be always equivalent and the latter
doesn't end up in some weird race/corner case I didn't consider (e.g.,
pseudo-files for which the stat.size == 0, but that the kernel can manage to
mmap them without problems. Is that possible on Windows? What about symlinks?) .


Curious side note. A method signature such as 
Foo(File, const FileRegion&)
where FileRegion has a ctor as the one you suggest is curiously very prone to
UAF by design, since File must be Pass()-ed. In other words, it is very tempting
to use such a method signature like this:
Foo(file.Pass(), FileRegion(file)), which would lead into a UAF of |file|, in
the 2nd argument by the FileRegion ctor. :-)

+
+    Region(int64 offset, int64 size);
+    ~Region();
+
+    // Whether the region intends to cover the entire file.
+    bool IsWholeFile() const;
+
+    // Start of the region (measured in bytes from the beginning of the file).
+    int64 offset;
+
+    // Length of the region.
+    int64 size;
+  };
+
   File();
 
   // Creates or opens the given file. This will fail with 'access denied' if the
   // |name| contains path traversal ('..') components.
   File(const FilePath& name, uint32 flags);
 
   // Takes ownership of |platform_file|.
   explicit File(PlatformFile platform_file);
 
   // Creates an object with a specific error_details code.
@@ skipping 136 matching lines @@
 #endif
 
   Error error_details_;
   bool created_;
   bool async_;
 };
 
 }  // namespace base
 
 #endif  // BASE_FILES_FILE_H_