Demonstrate hexnumber bug

[markus2330]

Basics

• [ ] Short descriptions of your changes are in the release notes (added as entry in doc/news/_preparation_next_release.md which contains _(my name)_) Please always add something to the release notes.
• [ ] Details of what you changed are in commit messages (first line should have module: short statement syntax)
• [ ] References to issues, e.g. close #X, are in the commit messages.
• [ ] The buildservers are happy. If not, fix in this order:
  • [ ] add a line in doc/news/_preparation_next_release.md
  • [ ] reformat the code with scripts/dev/reformat-all
  • [ ] make all unit tests pass
  • [ ] fix all memleaks
• [ ] The PR is rebased with current master.

Checklist

• [ ] I added unit tests for my code
• [ ] I fully described what my PR does in the documentation (not in the PR description)
• [ ] I fixed all affected documentation
• [ ] I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
• [ ] I updated all meta data (e.g. README.md of plugins and METADATA.ini)
• [ ] I mentioned every code not directly written by me in reuse syntax

Review

• [ ] Documentation is introductory, concise, good to read and describes everything what the PR does
• [ ] Examples are well chosen and understandable
• [ ] Code is conforming to our Coding Guidelines
• [ ] APIs are conforming to our Design Guidelines
• [ ] Code is consistent to our Design Decisions

Labels

• [ ] Add the "work in progress" label if you do not want the PR to be reviewed yet.
• [ ] Add the "ready to merge" label if the basics are fulfilled and no further pushes are planned by you.

[kodebach]

There are some commits in this PR that shouldn't be here...

As for the hexnumber bug: I'm not sure why it doesn't fail on kdb meta-set, but AFAIK hexnumber doesn't consider empty keys valid. So you need to first set the value and then the unit/base metakey. A secondary problem here is that hexnumber returns an error during kdbGet (instead of just a warning). I'm pretty sure that's why the kdb set call fails (during kdbGet the old value is not yet valid).

[markus2330]

The bug I have is actually:

Sorry, module type issued the error C03200:
Validation Semantic: The type 'unsigned_short' failed to match for 'default:/...' with string '0x21'
At: /mnt/data/libelektra/src/plugins/type/type.c:96

When trying to set an hexadecimal value, specified to be unsigned_short.

[markus2330]

If unit/base=hex is specified there is another bug when retrieving a value:

Sorry, module hexnumber issued the error C03100:
Validation Syntactic: Key 'default:/...' has unit/base metadata set as hex but value '33' does not start with 0x
At: /mnt/data/libelektra/src/plugins/hexnumber/hexnumber.c:354

The default is 0x21

[kodebach]

I'm pretty sure this is all still #2723. The default:/ namespace now exists, but on master backends for default:/ (including when implied by a cascading backend, e.g. via spec-mount) don't work properly. For example I'm pretty sure this breaks at least some parts https://github.com/ElektraInitiative/libelektra/blob/a5b8684ed10a939b94597e587730ae5b26b09128/src/libs/elektra/split.c#L183-L223

On the new-backend branch this should be fixed at some point. The basic ideas necessary are already outlined in doc/dev/kdb-operations.md (search for default:/).

[markus2330]

So let us fix #3626?

[kodebach]

How would fixing the origvalue issue help within anything here?

[markus2330]

I think the fundamental misuse of origvalue (it is designed that only a single plugin does transformations) is the cause of many usability problems in this area. If type takes the full responsibility for all these value transformations&checks such weird problems like rejecting transformed non-hex values that originally have been hex values should be impossible.

[kodebach]

1. origvalue was a bad design.
2. No type cannot take the responsibility for all transformations, unless there are "sub-plugins" which are called by type. (see #3626) It is not feasible for type know about all the possible conversions (color, hostnames, mac addresses, etc.)
3. Merging hexnumber into type is feasible and may be a good idea.
4. I still don't see how origvalue has anything to do with any of the issues in this PR (the build servers don't even report any issues anymore).