Crypto endpoint relation compare routines cleanup
* Trying not to assume an int is at least 32 bits. * Technically speaking, comparing "unrelated" addresses is undefined behaviour which can be avoided by a cast to uintptr_t. * The early out if either local_crypto == 0 does work in context, provided the nodes in tree never have local_crypto == 0. That implies crypto_insert_endpoint_relation must never have a 0 in there, which I think the callers do respect. Still I think it is better to not hide these assumptions in the compare function and address the problem in the lookup function instead. These changes likely make the code fractionally slower, but I do think they improve clarity. Signed-off-by: Erik Boasson <eb@ilities.com>
This commit is contained in:
parent
00710a4e5d
commit
99df0956e7
2 changed files with 17 additions and 27 deletions
|
@ -544,7 +544,7 @@ CU_TheoryDataPoints(ddssec_secure_communication, multiple_readers) = {
|
|||
CU_DataPoints(size_t, 1, 3, 1, 3), /* number of participants per domain */
|
||||
CU_DataPoints(size_t, 3, 1, 3, 3), /* number of readers per participant */
|
||||
};
|
||||
CU_Theory((size_t n_dom, size_t n_pp, size_t n_rd), ddssec_secure_communication, multiple_readers, .timeout = 60, .disabled = false)
|
||||
CU_Theory((size_t n_dom, size_t n_pp, size_t n_rd), ddssec_secure_communication, multiple_readers, .timeout = 90, .disabled = false)
|
||||
{
|
||||
DDS_Security_ProtectionKind metadata_pk[] = { PK_N, PK_SOA, PK_EOA };
|
||||
DDS_Security_BasicProtectionKind payload_pk[] = { BPK_N, BPK_S, BPK_E };
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue