Add VerifyHostFiles()

content_decryption_module.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 CDM_CONTENT_DECRYPTION_MODULE_H_
 #define CDM_CONTENT_DECRYPTION_MODULE_H_
 
+#include "content_decryption_module_export.h"

[xhwang, 2017/01/12 20:07:05]

We had the discussion about include path issue in the other code review:
https://chromiumcodereview.appspot.com/2446413003/

Here's a copy of that discussion for the reference:

----------------

* ddorwin:

Not LGTM due to path issue. This assumes the Chrome code structure, which may
not apply for other browsers.

* xhwang:

Can we just have this here:

#include "content_decryption_module_export.h"

I *think* the current folder will always be searched (I could be wrong). The
risk is that we may have another content_decryption_module_export.h somewhere in
the include path, but I  *think* the "current folder" is always searched first:

https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx

----------------

+
 #if defined(_MSC_VER)
 typedef unsigned char uint8_t;
 typedef unsigned int uint32_t;
 typedef int int32_t;
 typedef __int64 int64_t;
 #else
 #include <stdint.h>
 #endif
 
-// Define CDM_API so that functionality implemented by the CDM module
-// can be exported to consumers. Note: the implementation lives in
-// a dynamic library even in a non-component build.
-// Also define CDM_CLASS_API to export class types. We have to add
-// visibility attributes to make sure virtual tables in CDM consumer
-// and CDM implementation are the same. Generally, it was always a
-// good idea, as there're no guarantees about that for the internal
-// symbols, but it has only become a practical issue after
-// introduction of LTO devirtualization. See more details on
+// Define CDM_CLASS_API to export class types. We have to add visibility
+// attributes to make sure virtual tables in CDM consumer and CDM implementation
+// are the same. Generally, it was always a good idea, as there're no guarantees
+// about that for the internal symbols, but it has only become a practical issue
+// after introduction of LTO devirtualization. See more details on
 // https://crbug.com/609564#c35
 #if defined(WIN32)
-
 #if defined(__clang__)
 #define CDM_CLASS_API [[clang::lto_visibility_public]]
 #else
 #define CDM_CLASS_API
 #endif
-
-#if defined(CDM_IMPLEMENTATION)
-#define CDM_API __declspec(dllexport)
-#else
-#define CDM_API __declspec(dllimport)
-#endif  // defined(CDM_IMPLEMENTATION)
-
 #else  // defined(WIN32)
-#define CDM_API __attribute__((visibility("default")))
 #define CDM_CLASS_API __attribute__((visibility("default")))
 #endif  // defined(WIN32)
 
 // The version number must be rolled when the exported functions are updated!
 // If the CDM and the adapter use different versions of these functions, the
 // adapter will fail to load or crash!
 #define CDM_MODULE_VERSION 4
 
 // Build the versioned entrypoint name.
 // The extra macros are necessary to expand version to an actual value.
@@ skipping 832 matching lines @@
   virtual AudioFormat Format() const = 0;
 
  protected:
   AudioFrames() {}
   virtual ~AudioFrames() {}
 };
 
 }  // namespace cdm
 
 #endif  // CDM_CONTENT_DECRYPTION_MODULE_H_