[refactor] Remove WebArrayBuffer from unittests, since now using std::vector.

[refactor] Remove WebArrayBuffer from unittests, since now using std::vector.

This is a cleanup following https://codereview.chromium.org/233733004/.

BUG=245025
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=267375

[eroman, 2014-04-29 03:03:10]

This depends on https://codereview.chromium.org/233733004/

[Ryan Sleevi, 2014-04-30 02:10:00]

LGTM, mod nits

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
File content/child/webcrypto/crypto_data.h (left):

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/crypto_data.h:49: DISALLOW_COPY_AND_ASSIGN(CryptoData);
Why delete this?

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
File content/child/webcrypto/shared_crypto_unittest.cc (right):

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:77: *os << "[" <<
base::HexEncode(data.bytes(), data.byte_length()) << "]";
IINM, the old form would wrap strings, wouldn't it?

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:332: // Given a vector of
vectors, determines if there are any copies.
nit: This comment is ambiguous. Are you looking for the same logical object
(&this == &that), or merely, that their contents are indentical?

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:485: if (output.size() * 8 <
tag_length_bits) {
Huh. This smells odd. size() is a size_t. Doesn't it make more sense to do
tag_length_bytes = ((tag_length_bits+7)/8) ?

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:492: output.begin() +
(output.size() - tag_length_bits / 8));
Using tag_length_bytes would also make this clearer

eg: 17 bits = 2 bytes = "smells wrong" at first, until you realize that
->assign() ignores .end().

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:494: output.begin() +
output.size());
output.end()?

[eroman, 2014-04-30 18:35:53]

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
File content/child/webcrypto/crypto_data.h (left):

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/crypto_data.h:49: DISALLOW_COPY_AND_ASSIGN(CryptoData);
On 2014/04/30 02:10:01, Ryan Sleevi wrote:
> Why delete this?

In order to get the copy constructor. The macros I added to the tests wrap the
inputs in CryptoData(argument), and sometimes argument is a CryptoData.

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
File content/child/webcrypto/shared_crypto_unittest.cc (right):

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:77: *os << "[" <<
base::HexEncode(data.bytes(), data.byte_length()) << "]";
On 2014/04/30 02:10:01, Ryan Sleevi wrote:
> IINM, the old form would wrap strings, wouldn't it?

Not sure what you mean. The old way was to call ArrayBufferMatches() which does
not print any information about what expected/actual were. The new mechanism
improves the logging by using the built in EXPECT_EQ(), and dumping the hex data
on failure.

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:332: // Given a vector of
vectors, determines if there are any copies.
On 2014/04/30 02:10:01, Ryan Sleevi wrote:
> nit: This comment is ambiguous. Are you looking for the same logical object
> (&this == &that), or merely, that their contents are indentical?

Contents equality. Not sure how it is possible for &this to equal &that given
that the contents are not pointers. Anyhow changed the comments (it's edit was
from a search/replace).

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:485: if (output.size() * 8 <
tag_length_bits) {
On 2014/04/30 02:10:01, Ryan Sleevi wrote:
> Huh. This smells odd. size() is a size_t. Doesn't it make more sense to do
> tag_length_bytes = ((tag_length_bits+7)/8) ?

This is a guard against the line below which uses (output.size() -
tag_length_bits / 8).

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:492: output.begin() +
(output.size() - tag_length_bits / 8));
On 2014/04/30 02:10:01, Ryan Sleevi wrote:
> Using tag_length_bytes would also make this clearer
> 
> eg: 17 bits = 2 bytes = "smells wrong" at first, until you realize that
> ->assign() ignores .end().

I have updated the code to make this clearer:

The expectation is that upon reaching here, tag_length_bits is a multiple of 8
(if it wasn't Encrypt() should have failed since that is not a supported tag
length by webcrypto).

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:494: output.begin() +
output.size());
On 2014/04/30 02:10:01, Ryan Sleevi wrote:
> output.end()?

Done.

[Ryan Sleevi, 2014-04-30 18:40:39]

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
File content/child/webcrypto/shared_crypto_unittest.cc (right):

https://codereview.chromium.org/251213006/diff/40001/content/child/webcrypto/...
content/child/webcrypto/shared_crypto_unittest.cc:485: if (output.size() * 8 <
tag_length_bits) {
On 2014/04/30 18:35:53, eroman wrote:
> On 2014/04/30 02:10:01, Ryan Sleevi wrote:
> > Huh. This smells odd. size() is a size_t. Doesn't it make more sense to do
> > tag_length_bytes = ((tag_length_bits+7)/8) ?
> 
> This is a guard against the line below which uses (output.size() -
> tag_length_bits / 8).

Sorry I wasn't clearer on the smell - you're multiplying a potentially large
size and potentially overflowing. You will never have that issue with
tag_length_bits and dividing, but you run the risk of overflowing / weird
outputs with multiplying.

[eroman, 2014-04-30 19:47:01]

The CQ bit was checked by eroman@chromium.org

[commit-bot: I haz the power, 2014-04-30 19:48:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/eroman@chromium.org/251213006/100001

[commit-bot: I haz the power, 2014-04-30 23:27:54]

Change committed as 267375