Use the exact-width integer types defined in <stdint.h> rather than

Use the exact-width integer types defined in <stdint.h> rather than
"base/basictypes.h" in net/android, net/base, and net/cert.

R=eroman@chromium.org
BUG=488550
TEST=none

Committed: https://crrev.com/69f8ea8811eabe16f4793d15c8e211805d29dbe7
Cr-Commit-Position: refs/heads/master@{#332742}

[wtc, 2015-06-03 18:35:25]

wtc@chromium.org changed reviewers:
+ asanka@chromium.org

[eroman, 2015-06-03 19:01:02]

* What stuff do you want me to review (as there are 2 reviewers)
* There was a patch failure, shall I wait before reviewing?

[eroman, 2015-06-03 19:02:20]

Oh I see now this was not actually published, nevermind!

(I sometimes go through the web UI directly and end up reviewing anything where
I am set as reviewer)

[wtc, 2015-06-03 21:00:01]

wtc@chromium.org changed reviewers:
- asanka@chromium.org

[wtc, 2015-06-03 21:00:35]

Eric: this CL is now ready for your review. Please review the
entire CL. Thanks.

[eroman, 2015-06-03 22:10:40]

lgtm

https://codereview.chromium.org/1158923005/diff/60001/net/cert/crl_set_storag...
File net/cert/crl_set_storage.cc (right):

https://codereview.chromium.org/1158923005/diff/60001/net/cert/crl_set_storag...
net/cert/crl_set_storage.cc:118: memcpy(&header_len, data->data(), 2);  //
Assumes little-endian.
your translation is correct fine. however it seems like this file would be
better using sizeof(header_len) and the like throughout. In some cases it is
hard-coded (here, however in others it uses the size of the type).

https://codereview.chromium.org/1158923005/diff/60001/net/cert/crl_set_storag...
net/cert/crl_set_storage.cc:152: memcpy(&num_serials, data->data(),
sizeof(uint32_t));
for instance here sizeof(num_serials) would be more robust.

Also not sure how this file is used, but not sure that relying on little
endian-ness is a good idea, since can't we run on architectures (i.e. arm) which
are not?

food for thought, no changes needed in your change.

[wtc, 2015-06-03 22:31:37]

The CQ bit was checked by wtc@chromium.org

[commit-bot: I haz the power, 2015-06-03 22:32:16]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1158923005/60001

[commit-bot: I haz the power, 2015-06-04 00:08:23]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-06-04 00:09:29]

Patchset 4 (id:??) landed as
https://crrev.com/69f8ea8811eabe16f4793d15c8e211805d29dbe7
Cr-Commit-Position: refs/heads/master@{#332742}

[wtc, 2015-06-04 01:03:05]

https://codereview.chromium.org/1158923005/diff/60001/net/cert/crl_set_storag...
File net/cert/crl_set_storage.cc (right):

https://codereview.chromium.org/1158923005/diff/60001/net/cert/crl_set_storag...
net/cert/crl_set_storage.cc:118: memcpy(&header_len, data->data(), 2);  //
Assumes little-endian.

On 2015/06/03 22:10:39, eroman wrote:
> your translation is correct fine. however it seems like this file would be
> better using sizeof(header_len) and the like throughout. In some cases it is
> hard-coded (here, however in others it uses the size of the type).

Done. See https://codereview.chromium.org/1170493002/

https://codereview.chromium.org/1158923005/diff/60001/net/cert/crl_set_storag...
net/cert/crl_set_storage.cc:152: memcpy(&num_serials, data->data(),
sizeof(uint32_t));

On 2015/06/03 22:10:39, eroman wrote:
> Also not sure how this file is used, but not sure that relying on little
> endian-ness is a good idea, since can't we run on architectures (i.e. arm)
which
> are not?

ARM, MIPS, and PowerPC can be configured to be big-endian or little-endian.
Because of the popularity of little-endian processors, ARM, etc. are often
configured in little-endian mode to make software porting easier. Also, even
if one wants to write endianness-neutral code, it is very difficult to find
a big-endian computer to test the code on.

This is why I think it is OK to just assume little endian in Chromium.