Update from https://crrev.com/316786

base/files/file_path.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.
 
 // FilePath is a container for pathnames stored in a platform's native string
 // type, providing containers for manipulation in according with the
 // platform's conventions for pathnames.  It supports the following path
 // types:
 //
 //                   POSIX            Windows
@@ skipping 35 matching lines @@
 // at all, making them safe to use without fear of blocking on I/O operations.
 // These methods do not function as mutators but instead return distinct
 // instances of FilePath objects, and are therefore safe to use on const
 // objects.  The objects themselves are safe to share between threads.
 //
 // To aid in initialization of FilePath objects from string literals, a
 // FILE_PATH_LITERAL macro is provided, which accounts for the difference
 // between char[]-based pathnames on POSIX systems and wchar_t[]-based
 // pathnames on Windows.
 //
-// Paths can't contain NULs as a precaution agaist premature truncation.
+// As a precaution against premature truncation, paths can't contain NULs.
 //
 // Because a FilePath object should not be instantiated at the global scope,
 // instead, use a FilePath::CharType[] and initialize it with
 // FILE_PATH_LITERAL.  At runtime, a FilePath object can be created from the
 // character array.  Example:
 //
 // | const FilePath::CharType kLogFileName[] = FILE_PATH_LITERAL("log.txt");
 // |
 // | void Function() {
 // |   FilePath log_file_path(kLogFileName);
 // |   [...]
 // | }
 //
 // WARNING: FilePaths should ALWAYS be displayed with LTR directionality, even
 // when the UI language is RTL. This means you always need to pass filepaths
 // through base::i18n::WrapPathWithLTRFormatting() before displaying it in the
 // RTL UI.
 //
 // This is a very common source of bugs, please try to keep this in mind.
 //
 // ARCANE BITS OF PATH TRIVIA
 //
 //  - A double leading slash is actually part of the POSIX standard.  Systems
 //    are allowed to treat // as an alternate root, as Windows does for UNC
 //    (network share) paths.  Most POSIX systems don't do anything special
 //    with two leading slashes, but FilePath handles this case properly
 //    in case it ever comes across such a system.  FilePath needs this support
 //    for Windows UNC paths, anyway.
 //    References:
-//    The Open Group Base Specifications Issue 7, sections 3.266 ("Pathname")
+//    The Open Group Base Specifications Issue 7, sections 3.267 ("Pathname")
 //    and 4.12 ("Pathname Resolution"), available at:
-//    http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_266
+//    http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_267
 //    http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12
 //
 //  - Windows treats c:\\ the same way it treats \\.  This was intended to
 //    allow older applications that require drive letters to support UNC paths
 //    like \\server\share\path, by permitting c:\\server\share\path as an
 //    equivalent.  Since the OS treats these paths specially, FilePath needs
 //    to do the same.  Since Windows can use either / or \ as the separator,
 //    FilePath treats c://, c:\\, //, and \\ all equivalently.
 //    Reference:
 //    The Old New Thing, "Why is a drive letter permitted in front of UNC
@@ skipping 358 matching lines @@
 template<>
 struct hash<base::FilePath> {
   size_t operator()(const base::FilePath& f) const {
     return hash<base::FilePath::StringType>()(f.value());
   }
 };
 
 }  // namespace BASE_HASH_NAMESPACE
 
 #endif  // BASE_FILES_FILE_PATH_H_