Commit graph

5 commits

Author SHA1 Message Date
Jason Rhinelander
b627b3b4bb Move epee includes under "epee/..."
This ends epee's include pollution.
2020-10-24 12:46:27 -03:00
Jason Rhinelander
9ca1056f7f Post-merge updates: epee::is_byte_spannable
Fixes the temporary workarounds added for pre-C++17 is_byte_spannable.
2020-07-02 12:52:13 -03:00
Jason Rhinelander
7636155ffc Temporary clang variable template workaround
Temporary in that this will go away (in favour of become `inline`
variables) in the C++17 PR.
2020-06-09 23:06:54 -03:00
Jason Rhinelander
d66e6e9e3f Align hashable data structures
We don't impose any alignment on hashable types, but this means the
hashing function is doing invalid misaligned access when converting to a
size_t.  This aligns all of the primitive data types (crypto::hash,
public keys, etc.) to the same alignment as size_t.

That cascades into a few places in epee which only allow byte spanning
types that have byte alignment when what it really requires is just that
the type has no padding.  In C++17 this is exactly the purpose of
std::has_unique_object_representations, but that isn't available (or
even implementable) in C++14 so add specializations for the type that
need it to tell epee that we know those types are properly packed and
that it can safely use them as bytes.

Related to this, monero/epee also misuses `is_standard_layout` when the
purpose is actually `is_trivially_copyable`, so fixed that too.  (You
need the latter but don't need the former for a type to be safely
memcpy'able; the only purpose of `is_standard_layout` is when you need
to be sure your structs are compatible with C structs which is
irrelevant here).
2019-11-27 14:07:52 -04:00
Lee Clagett
0c7e7bce18 Adding classes, functions, and utilities for common LMDB operations. 2019-03-19 17:52:26 +00:00