Add unsigned 64-bit numeric config in module API#1546
Conversation
Signed-off-by: artikell <739609084@qq.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## unstable #1546 +/- ##
============================================
- Coverage 75.05% 74.92% -0.14%
============================================
Files 129 129
Lines 71553 71677 +124
============================================
- Hits 53705 53702 -3
- Misses 17848 17975 +127
🚀 New features to boost your workflow:
|
Signed-off-by: artikell <739609084@qq.com>
9787901 to
6156c1c
Compare
Signed-off-by: skyfirelee <739609084@qq.com>
|
Is there a concrete need for this, or are you just looking to make the API more usable by extending the use cases? We had discussed previously in Redis, and had decided to avoid having a large number of APIs, we would only support signed until someone indicated they clearly needed a 64 bit unsigned value. You can always restrict the value to be positive and cast it to unsigned (but just miss some of the high values). |
Yes, we encountered some scenarios. In some designs, uint64 is used as the ID, and the higher bits are used to store some information. However, for the |
Hmm, interesting. OK, that makes sense to me. |
|
Do you have any suggestions regarding this PR? Maybe you can help review it? Thank you. @madolson |
|
Hey yes! Sorry, it wasn't on my list for 8.1, I'm just now catching up on other items. Will prioritize it tomorrow. |
madolson
left a comment
There was a problem hiding this comment.
Mostly looks good to me, just some comments about structure and if we can simplify the new API.
| result = ValkeyModule_RegisterNumericConfig(ctx, "numeric", -1, VALKEYMODULE_CONFIG_DEFAULT, -5, 2000, getNumericConfigCommand, setNumericConfigCommand, longlongApplyFunc, &longval); | ||
| response_ok |= (result == VALKEYMODULE_OK); | ||
|
|
||
| result = ValkeyModule_RegisterUnsignedNumericConfig(ctx, "unsigned_numeric", 1, VALKEYMODULE_CONFIG_DEFAULT | VALKEYMODULE_CONFIG_UNSIGNED, 0, LLONG_MAX * 1ULL + 1000, getUnsignedNumericConfigCommand, setUnsignedNumericConfigCommand, unsignedlonglongApplyFunc, &mutable_ull_val); |
There was a problem hiding this comment.
I'm not sure why we need both the API and the new enum value. Can't RegisterUnsignedNumericConfig imply VALKEYMODULE_CONFIG_UNSIGNED ? We need the new API anyways because there are typed differences.
There was a problem hiding this comment.
That can be implemented, but it will introduce some difficult to understand issues because the parameters of the ValkeyModule_RegisterNumericConfig method are all of type long long. For example, min and max values.
What's your opinion?
| @@ -1,9 +1,12 @@ | |||
| #include "valkeymodule.h" | |||
| #include <strings.h> | |||
| #include <limits.h> | |||
There was a problem hiding this comment.
Yes, the LLONG_MAX constant was used
| unsigned long long ull; | ||
| int ok = string2ull(value, sdslen(value), &ull); | ||
| if (ok) { | ||
| *res = (long long)ull; |
There was a problem hiding this comment.
This feels weird, we're casting this to a ll and then casting it back. I originally thought this truncated the top bit, but apparently it preserves the bit pattern. I still think we maybe should have a dedicated function for handling unsigned numerics here.
There was a problem hiding this comment.
This is a reference to the implementation of memtoull in the MEMORY_CONFIG configuration.
Do you mean a similar method needs to be implemented to cast the operation? Or add a numericParseString method for unsigned types?
There was a problem hiding this comment.
I think this is fine, but let's add some code comments about it. When parsing an unsigned number, although it's returned as a signed number, the caller needs to interpret it as an unsigned long long.
This is what getModuleUnsignedNumericConfig and other functions do.
Signed-off-by: artikell <739609084@qq.com>
3fe194c to
5124b35
Compare
In fact, unsigned longlong is special because its numerical range is the largest. For other types of data, it is not necessary to use an unsigned type, just control the data range. Add an API that can also defend against a large number of type casts in encoding, avoiding various errors caused by them. |
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
- Fix release date to Mon Mar 18 2026 - Fix typos: duplicate 'load', 'keyes' -> 'keys', duplicate 'INFO' - Remove reverted contributor (arshidkv12, valkey-io#3137) - Add 7 new release-notes entries from upstream/unstable merge: CLUSTERSCAN (valkey-io#2934), MSETEX (valkey-io#3121), availability-zone (valkey-io#3156), stream range optimization (valkey-io#3002), RDB as AOF preamble (valkey-io#1901), unsigned 64-bit module config (valkey-io#1546), fast_float -> ffc (valkey-io#3329) Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
- Supports `VALKEYMODULE_CONFIG_UNSIGNED` and `UNSIGNED_CONFIG` for a wider range of configurations. - Supported the API for `ValkeyModule_RegisterUnsignedNumericConfig` - `string2ull` method supports the length parameter, making it more secure --------- Signed-off-by: artikell <739609084@qq.com> Signed-off-by: skyfirelee <739609084@qq.com> Signed-off-by: Madelyn Olson <madelyneolson@gmail.com> Co-authored-by: Madelyn Olson <madelyneolson@gmail.com>
VALKEYMODULE_CONFIG_UNSIGNEDandUNSIGNED_CONFIGfor a wider range of configurations.ValkeyModule_RegisterUnsignedNumericConfigstring2ullmethod supports the length parameter, making it more secure