RTCPeerConnection.generateCertificate taking AlgorithmIdentifier and using WebCrypto

third_party/WebKit/public/platform/WebCryptoUtil.h

Index: third_party/WebKit/public/platform/WebCryptoUtil.h
diff --git a/third_party/WebKit/public/platform/WebCryptoUtil.h b/third_party/WebKit/public/platform/WebCryptoUtil.h
new file mode 100644
index 0000000000000000000000000000000000000000..67bc5de9b2af60ab4534c1cdac2016f45d56a3a2
--- /dev/null
+++ b/third_party/WebKit/public/platform/WebCryptoUtil.h
@@ -0,0 +1,30 @@
+// Copyright 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 WebCryptoUtil_h
+#define WebCryptoUtil_h
+
+#include "WebCommon.h"
+#include "WebVector.h"
+
+namespace blink {
+
+// Converts the (big-endian) BigInteger to unsigned int. Returns true on success (if its value is not too large).
+static bool bigIntegerToUint(const WebVector<unsigned char>& bigInteger, unsigned& result)

[tommi (sloooow) - chröme, 2015/10/26 17:18:03]

static method in a header file - won't this cause linker errors if more than one
object files use it?

[eroman, 2015/10/26 18:02:10]

Regardless whether this compiles or not, it is undesirable as it defines an
inline function.

Instead put the function declaration here, mark it as BLINK_PLATFORM_EXPORT, and
then provide the definition in a corresponding C++ file (which will be in the
exported subdirectory).

See other files for an example.

[hbos_chromium, 2015/10/27 08:50:20]

I thought I could not use .cc files because everything in the folder was header
files and thought this was a good compromise, my bad, there are plenty of
examples of .cc's in exported/. I should of course do the same!

But FYI, this would not have caused linker errors and it would not have been
inlined.
  @tommi It's a global function, not a method. If it was not static we would get
linker errors, but static in the context of global functions (this bad boy
keyword means very different things in different contexts) means it shall not be
exposed to other compilation units. Thus it is safe, however, each compilation
unit (.cc) that uses the function will get its own copy of the function code.
  @eroman While it is true that member functions implicitly get inlined when
defined in the header (or rather, in the class definition, if you want to be
picky) this is not true for normal functions. This would be like any helper
function in a .cc file.
  Moving it to .cc file as suggested is the best approach. Then each compilation
unit will not get a copy of the function and the next person who stumbles upon
my code will not run into the same confusion as above.

+{
+    result = 0;
+    for (size_t i = 0; i < bigInteger.size(); ++i) {
+        size_t iReversed = bigInteger.size() - i - 1;
+
+        if (iReversed >= sizeof(result) && bigInteger[i])
+            return false; // Too large for unsigned int.
+
+        result |= bigInteger[i] << 8 * iReversed;
+    }
+    return true;
+}
+
+} // namespace blink
+
+#endif // WebCryptoUtil_h