From fa5e809f465fc25d2872fe85983632b77f290062 Mon Sep 17 00:00:00 2001 From: vnugent Date: Mon, 12 Aug 2024 13:57:11 -0400 Subject: Squashed commit of the following: commit a6392806eae7f302031afbcf22664ba33cbc4ad1 Author: vnugent Date: Mon Aug 12 13:56:03 2024 -0400 simple cleanup & some api notes commit a97012676cc836ec50ef5ff6d8e97134aa7a1d22 Merge: ec7461d fb3608b Author: vnugent Date: Wed Aug 7 21:39:28 2024 -0400 Merge branch 'master' into develop --- include/noscrypt.h | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'include') diff --git a/include/noscrypt.h b/include/noscrypt.h index 574cef9..3702555 100644 --- a/include/noscrypt.h +++ b/include/noscrypt.h @@ -125,6 +125,27 @@ extern "C" { #define NC_ENC_SET_NIP44_MAC_KEY 0x03 #define NC_ENC_SET_NIP04_KEY 0x04 +/* +* API NOTES: +* +* - Decisions on integer width +* Since noscrypt will target general purpose processors and embedded +* systems (future) I didn't want to risk word size issues causing under/overflow +* for the time being, so a fixed integer width was used and internal code +* supports and guards against the platform default integer width (size_t) +* +* I'd like to support 64bit stuff, but really the underlying systems don't +* need to support that size buffer, nor do I expect platforms to have more than +* 4GB sized buffers (int32_t), it's just not practial and most work is on +* digests anyway. +* +* - Decisions on unsigned vs signed +* Yeah, I know this is a popular squabble in C land, but implementation details +* should not trouble the user. If I expect an unsigned int, then it should be +* explicit, negative number guards are cumbersom to handle return codes with +* that IMO most engineers don't bother doing anyway or doing well at the very +* least, so I'm using unsgined integers. Sorry, not sorry. +*/ /* A compressed resul/return value, negative values are failure, 0 is success and positive values are -- cgit