Skip to content
This repository has been archived by the owner on Oct 15, 2024. It is now read-only.

elektraKeyCmpOrder with order = 0 #3274

Closed
bauhaus93 opened this issue Nov 24, 2019 · 4 comments
Closed

elektraKeyCmpOrder with order = 0 #3274

bauhaus93 opened this issue Nov 24, 2019 · 4 comments
Assignees

Comments

@bauhaus93
Copy link
Contributor

Does a order metakey with value 0 have any special meaning (I couldn't find any information on it in METADATA.ini)?

Otherwise I think the elektraKeyCmpOrder function does not work as intended. While working on the toml plugin, I got an unexpected ordering of my Key array after sorting it with the help of elektraKeyCmpOrder.

Expected Result

I expected a Key with order metakey 0 to be sorted before a key with order 1.

Actual Result

The Key with order = 0 wasn't sorted as first element, but between the keys with order 101 and 102.

Steps to Reproduce the Problem

When I looked into the implementation of elektraKeyCmpOrder I saw that when I compare 0 with any other positive number, none of the if branches will get taken and the return 0 is taken, after the cannot happen anyway comment.
Relevant elektraKeyCmpOrder code:

if (aorder > 0 && border > 0) return aorder - border;
if (aorder < 0 && border < 0) return 0;
if (aorder < 0 && border >= 0) return -1;
if (aorder >= 0 && border < 0) return 1;
/* cannot happen anyway */
return 0;

For example, let aorder be 0 and border be 1, then no branch is taken since

(0 > 0 && 1 > 0) -> false
(0 < 0 && 1 < 0) -> false
(0 < 0 && 1 >= 0) -> false
(0 >= 0 && 1 < 0) -> false

or if aorder = 1 and border = 0

(1 > 0 && 0 > 0) -> false
(1 < 0 && 0 < 0) -> false
(1 < 0 && 0 >= 0) -> false
(1 >= 0 && 0 < 0) -> false

For both cases the function returns 0, meaning that the keys are equal in ordering.

@markus2330
Copy link
Contributor

Thank you for reporting this bug!

Does a order metakey with value 0 have any special meaning

No.

after the cannot happen anyway comment.

Sounds like a bug, an assert would have been helpful there.

Feel free to change the implementation of elektraKeyCmpOrder as you want.

One idea was to also allow suborders like 0.1.2. This might be useful for sections (the first number counts the section, the second the key and so on).

In any case, please improve the docu in doc/METADATA.ini. At the moment the docu does not contain any example, nor which range of numbers is allowed (which seems to have made you very unsure if this is a bug).

@kodebach
Copy link
Member

One idea was to also allow suborders like 0.1.2.

If we prefix the integer(s) with _ (like we do in array element keys), a simple strcmp should deliver the expected result. Then there would be no need for atoi (which is another bug waiting to happen):

int elektraKeyCmpOrder (const Key * ka, const Key * kb)
{
        // keyGetMeta is NULL, if key is NULL
	const Key * kam = keyGetMeta (ka, "order");
	const Key * kbm = keyGetMeta (kb, "order");

	if (ka == kb) return 0; // same pointer (including both NULL)
	if (ka == NULL) return -1;
	if (kb == NULL) return 1;

	return strcmp (keyString (kam), keyString(kbm));
}

If the special case for negative numbers has to be preserved, this won't work of course.

@markus2330
Copy link
Contributor

Yes, having a simple strcmp with with /#1/#_10 arrays would also be possible. But this would require to rewrite all plugins....

bauhaus93 added a commit to bauhaus93/libelektra that referenced this issue Jan 16, 2020
Fixes ElektraInitiative#3274.
The elektraKeyCmpOrder function no longer considers order values of 0 as equal with any other positive integer.
@markus2330
Copy link
Contributor

will be closed by #3292

bauhaus93 added a commit to bauhaus93/libelektra that referenced this issue May 7, 2020
Keys with order zero or less are now sorted properly.
bauhaus93 added a commit to bauhaus93/libelektra that referenced this issue May 8, 2020
Keys with order zero or less are now sorted properly.
bauhaus93 added a commit to bauhaus93/libelektra that referenced this issue Jun 9, 2020
Keys with order zero or less are now sorted properly.
@mpranj mpranj closed this as completed in 67e9c49 Sep 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants