Add support for loading pak files from arbitrary file regions.

base/files/file.h

Index: base/files/file.h
diff --git a/base/files/file.h b/base/files/file.h
index 1913bc7f6c408c8e1e3840da712895ff2fd88259..c20df5c3edcde03d8c1e09a0074101721f278e3b 100644
--- a/base/files/file.h
+++ b/base/files/file.h
@@ -155,6 +155,23 @@ class BASE_EXPORT 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