Fix crash in HasKeyBag on SPARC Solaris 11
#2196
Conversation
hopefully the compiler is clever enough to optimise this away
There was a problem hiding this comment.
This looks OK in principle to me, however, it would be even better if there was an explanatory comment here. Something like this:
The pointer p may not be aligned, which means that directly writing to it can incur a major performance penalty or even trigger a segfault on certain architectures (e.g. ARM, SPARC). Thus we use
memcpyhere, with the implicit hope that on archs which don't need this, the compiler will optimize it back into a direct copy (verified to happen with GCC and clang on x86_64)
|
Should I amend the commit to include the paragraph suggested above? |
|
This comment really should be in the code, not the commit message (where it is invisible when reading the code) |
OK, done. |
src/intfuncs.c
Outdated
| @@ -307,10 +307,18 @@ static inline uint64_t rotl64 ( uint64_t x, int8_t r ) | |||
| //----------------------------------------------------------------------------- | |||
| // Block read - if your platform needs to do endian-swapping or can only | |||
| // handle aligned reads, do the conversion here | |||
| // | |||
| // The pointer p may not be aligned, which means that directly writing to it can | |||
There was a problem hiding this comment.
very picky, it's "reading it", not "writing to it"
fingolfin
changed the title
fingolfin
added
kind: bug
fingolfin
changed the title
HasKeyBag on SPARC Solaris 11
fingolfin
added
the
release notes: added
hopefully the compiler is clever enough to optimise this away