Open damiengermonville opened 10 years ago
Hi again,
I'm using the same issue to report a slight mistake in the CPESet2_3._compare() method (well, if I'm using correctly).
On both lines 105 and 109: https://github.com/nilp0inter/cpe/blob/develop/cpe/cpeset2_3.py#L105 https://github.com/nilp0inter/cpe/blob/develop/cpe/cpeset2_3.py#L109
The values of attributes (target and source) are compared to CPEComponent2_3_WFN.VALUE_ANY (the 'ANY' string). However, the values received as arguments are not WFN values but FS values, i.e. receives the asterisk char and compares it to 'ANY'.
I think that CPEComponent2_3_FS.VALUE_ANY should be used instead, or that the conversion from FS attributes to WFN attr should be done before.
Again, I only tested that behavior on CPE2_3 objects.
Thanks
Upvoting the forge by geekoftheweek. Solves the problem.
Hi
I'm back for another question :) I'm not sure if this is a bug or the expected behavior. When using CPESet to perform name matching, the asterisk alone is considered as a string containing a wildcard instead of the value ANY: https://github.com/nilp0inter/cpe/blob/develop/cpe/cpeset2_3.py#L201
However, this has (in my opinion) some strange results such as the following:
In my mind, the first call (_CPESet2_3.cpesuperset(c1, c)) would return True as c0 supersets c1. In fact, the method _CPESet2_3.compare() will return _CPESet2_3.LOGICAL_VALUEUNDEFINED because the target has a value ANY which is considered as a wildcard: https://github.com/nilp0inter/cpe/blob/develop/cpe/cpeset2_3.py#L95
I managed to get the expected result (still, from what I understood from the specs) by adding the following at the beginning of the _contains_wildcards() method.
Is there any other part of the specs implementation which needs to be fixed ? Or am I completely wrong about CPE name matching :D ?
_Note: my tests were only focused on CPESet23, I haven't had a look at the other versions.
May further testing be needed, please ask :)
Thanks !