Skip to content

Add unsigned 64-bit numeric config in module API#1546

Merged
zuiderkwast merged 5 commits into
valkey-io:unstablefrom
artikell:expand_num_range
Mar 11, 2026
Merged

Add unsigned 64-bit numeric config in module API#1546
zuiderkwast merged 5 commits into
valkey-io:unstablefrom
artikell:expand_num_range

Conversation

@artikell

Copy link
Copy Markdown
Contributor
  • 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>
@codecov

codecov Bot commented Jan 12, 2025

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 14.89362% with 40 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.92%. Comparing base (fc217fc) to head (8a777ed).
⚠️ Report is 16 commits behind head on unstable.

Files with missing lines Patch % Lines
src/config.c 23.07% 20 Missing ⚠️
src/module.c 4.76% 20 Missing ⚠️
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     
Files with missing lines Coverage Δ
src/server.h 100.00% <ø> (ø)
src/config.c 77.63% <23.07%> (-0.93%) ⬇️
src/module.c 26.38% <4.76%> (-0.08%) ⬇️

... and 27 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Signed-off-by: artikell <739609084@qq.com>
Signed-off-by: skyfirelee <739609084@qq.com>
@madolson

Copy link
Copy Markdown
Member

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).

@artikell

Copy link
Copy Markdown
Contributor Author

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.
Logically, use creatULongLongConfig to manage configurations.

However, for the creatULongLongConfig method, it can only exceed ULLONG_MAX in the MEMORY_CONFIG configuration item. so, I think we need a configuration to support a larger range.

@madolson

Copy link
Copy Markdown
Member

In some designs, uint64 is used as the ID, and the higher bits are used to store some information.
Logically, use creatULongLongConfig to manage configurations.

Hmm, interesting. OK, that makes sense to me.

@artikell

Copy link
Copy Markdown
Contributor Author

Do you have any suggestions regarding this PR? Maybe you can help review it? Thank you. @madolson

@madolson

Copy link
Copy Markdown
Member

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 madolson left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this used?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the LLONG_MAX constant was used

Comment thread src/redismodule.h Outdated
Comment thread src/config.c
unsigned long long ull;
int ok = string2ull(value, sdslen(value), &ull);
if (ok) {
*res = (long long)ull;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread tests/modules/moduleconfigs.c
Signed-off-by: artikell <739609084@qq.com>
@artikell

artikell commented Mar 2, 2025

Copy link
Copy Markdown
Contributor Author

Mostly looks good to me, just some comments about structure and if we can simplify the new API.

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.

@artikell artikell requested a review from madolson March 3, 2025 03:27
@madolson madolson added enhancement New feature or request major-decision-pending Major decision pending by TSC team labels Sep 5, 2025
@madolson madolson moved this to Todo in Valkey 9.1 Sep 5, 2025
@madolson madolson added major-decision-approved Major decision approved by TSC team and removed major-decision-pending Major decision pending by TSC team labels Oct 27, 2025
@madolson madolson moved this from Todo to Needs Review in Valkey 9.1 Feb 2, 2026
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
@zuiderkwast zuiderkwast changed the title Support unsigned numeric config Add unsigned 64-bit numeric config in module API Mar 11, 2026
@zuiderkwast zuiderkwast added the release-notes This issue should get a line item in the release notes label Mar 11, 2026
@zuiderkwast zuiderkwast merged commit 7403b42 into valkey-io:unstable Mar 11, 2026
92 checks passed
@github-project-automation github-project-automation Bot moved this from Needs Review to Done in Valkey 9.1 Mar 11, 2026
madolson added a commit to madolson/valkey that referenced this pull request Mar 15, 2026
- 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>
JimB123 pushed a commit that referenced this pull request Mar 19, 2026
- 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request major-decision-approved Major decision approved by TSC team release-notes This issue should get a line item in the release notes

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants