Removed Commit-Queue+1 by Tom Sepez <tse...@chromium.org>
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Previous mega-cq run hit only patch failed issues, CL now rebased.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
return !UNSAFE_TODO(memcmp(blob->bytes(), "RIFF", 4)) &&
Just a general question. In cases like this where we've checked `blob->size()` (line 115) to ensure it's large enough, is there a way to remove the `UNSAFE_TODO`?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
return !UNSAFE_TODO(memcmp(blob->bytes(), "RIFF", 4)) &&
Just a general question. In cases like this where we've checked `blob->size()` (line 115) to ensure it's large enough, is there a way to remove the `UNSAFE_TODO`?
If you wanted to keep the memcmp, you could write
```
// SAFETY: blob is at least 20 bytes per check above.
UNSAFE_BUFFERS(memcmp(blob->bytes(), "RIFF", 4))
```
But that's really no better, since if someone removes the check above in a future CL, you're no longer safe. We're at a little bit of a disadvantage that although blob->byteSpan() returns an SkSpan, its not quite as sophisticated as other span implementations. But it should be implicitly convertible to a base span
```
base::span<const uint8_t> blob_bytes(blob->byteSpan());
if (blob_bytes.size() < 20UL) {
return false;
}
return blob_bytes.first<4u>() == base::byte_span_from_cstring("RIFF");
```
With the this code, the compiler should be able to optimize out the bounds
check for 4u at compile time, but if someone were to remove the < 20 test, the bounds check would remain and CHECK() if span was too small.
Now to see if any of this actually compiles.
return !UNSAFE_TODO(memcmp(blob->bytes(), "RIFF", 4)) &&
Tom SepezJust a general question. In cases like this where we've checked `blob->size()` (line 115) to ensure it's large enough, is there a way to remove the `UNSAFE_TODO`?
If you wanted to keep the memcmp, you could write
```
// SAFETY: blob is at least 20 bytes per check above.
UNSAFE_BUFFERS(memcmp(blob->bytes(), "RIFF", 4))
```
But that's really no better, since if someone removes the check above in a future CL, you're no longer safe. We're at a little bit of a disadvantage that although blob->byteSpan() returns an SkSpan, its not quite as sophisticated as other span implementations. But it should be implicitly convertible to a base span
```
base::span<const uint8_t> blob_bytes(blob->byteSpan());
if (blob_bytes.size() < 20UL) {
return false;
}
return blob_bytes.first<4u>() == base::byte_span_from_cstring("RIFF");
```With the this code, the compiler should be able to optimize out the bounds
check for 4u at compile time, but if someone were to remove the < 20 test, the bounds check would remain and CHECK() if span was too small.Now to see if any of this actually compiles.
And just for the record, it takes a tiny bit more wrangling to satisfy the compiler and its temporary lifetime tracking (doesn't seem to understand that skspan is a borrowed range who's lifetime doesn't matter).
```
auto sk_blob_bytes = blob->byteSpan();
base::span<const uint8_t> blob_bytes(sk_blob_bytes);
if (blob_bytes.size() < 20UL) {
return false;
}
return blob_bytes.first<4u>() == base::byte_span_from_cstring("RIFF") &&
`
base::byte_span_with_nul_from_cstring("WEBPVP8");
```
What's interesting is that if I write
```
blob_bytes.subspan<8u, 8u>() ==
base::byte_span_with_nul_from_cstring("WEBPVP8");
```
it fails to compile complaining about an 8 vs 7 size mismatch. Hopefully the spec says that there needs to be a \0 in the 16th byte of the input, or you'd really want to compare a subspan<8u, 7u>. Note that the new code makes it obvious that you are including the nul in the comparison (just looking at the memcmp I didn't realize that since I didn't realise "wevpvp8" is only 8 chars). So we moved a potential size mismatch to compile time ...
Code-Review | +1 |
lg
sorry for the slow review
one suggestion for your consideration, but fine as-is too
#endif
there's _so much_ in this file that it might make sense to keep a file-based pragma here
Needs re-stamp since I reverted the one file as suggested. Thanks!
there's _so much_ in this file that it might make sense to keep a file-based pragma here
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +2 |
return !UNSAFE_TODO(memcmp(blob->bytes(), "RIFF", 4)) &&
And just for the record, it takes a tiny bit more wrangling to satisfy the compiler and its temporary lifetime tracking (doesn't seem to understand that skspan is a borrowed range who's lifetime doesn't matter).
```
auto sk_blob_bytes = blob->byteSpan();
base::span<const uint8_t> blob_bytes(sk_blob_bytes);
if (blob_bytes.size() < 20UL) {
return false;
}
return blob_bytes.first<4u>() == base::byte_span_from_cstring("RIFF") &&
`
base::byte_span_with_nul_from_cstring("WEBPVP8");
```
What's interesting is that if I write
```
blob_bytes.subspan<8u, 8u>() ==
base::byte_span_with_nul_from_cstring("WEBPVP8");
```
it fails to compile complaining about an 8 vs 7 size mismatch. Hopefully the spec says that there needs to be a \0 in the 16th byte of the input, or you'd really want to compare a subspan<8u, 7u>. Note that the new code makes it obvious that you are including the nul in the comparison (just looking at the memcmp I didn't realize that since I didn't realise "wevpvp8" is only 8 chars). So we moved a potential size mismatch to compile time ...
Ah, so there ya go. The version landed had the unsafe_todo(), btw.
In other words, if someone were to clumsily loose the space at the end (ha), it would fail to compile in the spanified case.
Force-update unsafe buffers in third_party/blink
Update files regardless of presence of #ifdef sections which the
compiler might not have flagged. Then revert files that fail to
keep the diffs automated.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |