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

libelektra/src/libs/elektra/split.c

Lines 183 to 223 in a5b8684

	static ssize_t splitSearchBackend (Split * split, Backend * backend, Key * parent)
	{
	for (size_t i = 0; i < split->size; ++i)
	{
	if (backend == split->handles[i])
	{
	if (test_bit (split->syncbits[i], SPLIT_FLAG_CASCADING))
	{
	switch (keyGetNamespace (parent))
	{
	case KEY_NS_SPEC:
	if (keyIsSpec (split->parents[i])) return i;
	break;
	case KEY_NS_DIR:
	if (keyIsDir (split->parents[i])) return i;
	break;
	case KEY_NS_USER:
	if (keyIsUser (split->parents[i])) return i;
	break;
	case KEY_NS_SYSTEM:
	if (keyIsSystem (split->parents[i])) return i;
	break;
	case KEY_NS_PROC:
	return -1;
	case KEY_NS_NONE:
	return -1;
	case KEY_NS_META:
	return -1;
	case KEY_NS_CASCADING:
	return -1;
	case KEY_NS_DEFAULT:
	return -1;
	}
	continue;
	}
	/* We already have this backend, so leave */
	return i;
	}
	}
	return -1;
	}

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