Skip to content

Conversation

@hebasto
Copy link
Member

@hebasto hebasto commented Sep 7, 2024

A few more changes have been pulled from upstream:

The google#65 provides an alternative implementation to our #6, so the latter has been reverted.

Additionally, there is a conflict with our a3f2c1c. Should we keep it, or can it be reverted to resolve the conflict?

shlevy and others added 5 commits September 6, 2024 15:44
* Fix invalid pointer casts in arm64 implementation

It is UB in C and C++ to type-pun pointers in this way, for two reasons.
First, casting to a pointer is forbidden if the pointer is not aligned.
Second, this kind of type-punning is a strict aliasing violation.

Instead, the way to read 8 bytes as a time as a uint64_t is to call
memcpy. Compilers recognize this pattern and optimize it, lowering it to
the same code, but without breaking the language's abstract state
machine.

This is needed to fix some UBSan warnings in Chromium.

* Use crc32c_read_le.h instead

In doing so, I fixed up crc32c_read_le.h a bit:

1. The documentation and tests say the buffers need to be aligned, but
   they don't.

2. Add a 16-bit version.

3. Remove an unnecessary static_cast<uint8_t>. The pointer is already
   uint8_t.

4. Replace the necessary static_casts with uintN_t{x} per the Google
   style guide. https://google.github.io/styleguide/cppguide.html#Casting
@fanquake
Copy link
Member

fanquake commented Aug 7, 2025

Want to update this to also pull: google#68.

@maflcko
Copy link

maflcko commented Aug 7, 2025

Additionally, there is a conflict with our a3f2c1c. Should we keep it, or can it be reverted to resolve the conflict?

Looks like it was broken anyway (002cfa2), so may be best to revert for now and add it back, when there is need again for it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants