Fix incorrect coercing of json-object int to uint32 in sparse-array-lookup-table implementation

[janmejay]

Fix incorrect coercing of json-object int to uint32
in sparse-array-lookup-table implementation.

This aims to fix broken int-max case described
#4490 and
#4490.

[janmejay]

@rgerhards I haven't bumped libfastjson version. Do I need to? or is it ok to defer it to the release process?

[rgerhards]

@rgerhards I haven't bumped libfastjson version. Do I need to? or is it ok to defer it to the release process?

Requiring a new libfastjson is always a bit hard, as some distros may not carry it for many month. I would prefer if we could do a configure check on the version and emit a warning/error message if and only if the function in question is actually needed by current config. Does that make sense to you?

[janmejay]

@rgerhards I haven't bumped libfastjson version. Do I need to? or is it ok to defer it to the release process?

Requiring a new libfastjson is always a bit hard, as some distros may not carry it for many month. I would prefer if we could do a configure check on the version and emit a warning/error message if and only if the function in question is actually needed by current config. Does that make sense to you?

There was a line with incorrect formatting, fixed that.

Since lookup-table is always enabled, its part of the core, dependency isn't really optional.

[rgerhards]

Since lookup-table is always enabled, its part of the core, dependency isn't really optional.

yes, but if the config does not use any lookup table at all - then we do not need it, right? I think that's a very common case.

[rgerhards]

side-note: I have updated the Ubuntu 20.04 containers and re-initiated check runs for them - so we should get a result now

[janmejay]

yes, but if the config does not use any lookup table at all - then we do not need it, right? I think that's a very common case.

Compilation wouldn't succeed without the new function json_object_get_uint. So runtime check wouldn't be useful.

[rgerhards]

side-note: I have updated the Ubuntu 20.04 containers and re-initiated check runs for them - so we should get a result now

mistake on my side... will look into it

[rgerhards]

@janmejay FYI: I am working on updgrading the CI infrastructure to the new (yet-unreleased) librelp version. I'll let you know when I am done.

[rgerhards]

@janmejay FYI: I'll add e commit to your branch to force newer libfastjson and see how this works out

[rgerhards]

OK, I cannot simply add. Will create a new PR and then let's see what we can mege.

[rgerhards]

@janmejay please have a look at this result: https://build.rsyslog.com/#/builders/142/builds/5175/steps/4/logs/test-suite_log - there seems to be a problem on ARM platforms.

This is from #4507, which is basically your PR, plus an extra commit from my side. Feel free to cherry-pick it. If possible, I would appreciate if you could squash the end result to a single commit.

Note: some of the CI Platforms still fail due to too-old libfastjson (like Solaris), but that's a different matter. The majority should now work, including arm.

[rgerhards]

removing milestone as this PR looks stalled