| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It works on x86, but C says it is undefined and it makes UBSan
unhappy. Happily, this memcpy approach probably also works fine under
processors which previously used the byte-at-a-time approach such as
ARM. But for right now using memcpy here is still gated under the
processor alignment flags.
In my tests recent GCC and Clang seemed to produce basically identical
code for either approach when using -O3; I imagine most compilers
these days are very good at analyzing/inlining/unrolling memcpys.
Also remove the manually unrolled versions of xor_buf, which caused
problems with GCC and -O3 due to it vectorizing the loads into
(aligned) SSE2 loads, which would fail when a misaligned pointer was
passed. Which always seemed kind of bogus to me, but I guess that's
what undefined behavior is for. Enable -O3 for GCC.
With this change the test suite is clean under GCC ASan+UBSan and
Clang ASan+UBSan, with the exception of one failure due to a bug in
libstdc++ (GCC bug 60734) when compiled by Clang.
|
|
|
|
|
|
|
|
|
|
| |
Calling memset, memmove, memcpy with an undefined or null pointer,
even with length zero, causes undefined behavior. Prevent that from
happening within the functions that call these dangerous things
since allowing a caller to pass length == 0 with null or just
past the end and not have things explode is nice.
Oh C, you so crazy.
|
|
|
|
| |
Only user-visible change is the removal of get_byte.h
|
|
|
|
|
| |
Update license header line to specify the terms and refer to the file,
neither of which it included before.
|
|
|
|
|
| |
zero_mem just before a deallocation where we are actually at risk of
the compiler eliding the writes.
|
|
|