member$ bug fix in 64x r889

[denis.be...@gmail.com]

I see that r889  fixes a bug in function member$ in branch 64x.

1) Can you be more precise about what has been fixed? What was the scope of the bug? Could it appear anywhere or only in some  precise contexts? (Very important for me to know if  I must completely redo some recent calculations.)

2) There's no fix for the 63x branch. Does that mean there was no bug in it or that the 63x branch is no longer maintained.?

[CLIPS Support]

The index value returned by the member$ could be incorrect when the multifield value passed to the function was retrieved from a slot. Here's an example:

         CLIPS (6.4 2/9/21)
CLIPS>
(defrule bug
   (list ? ? $?v)
   =>
   (println (member$ c ?v)))
CLIPS> (assert (list a b c))
<Fact-1>
CLIPS> (run)
3
CLIPS> 

In this case, the value printed should be 1 rather than 3. This is occurring because CLIPS can internally represent multifields as a base multifield plus a starting index and a range. In this rule, the variable ?v passed to the member$ function is the multifield (a b c), the value of the implied slot for the list fact, and the starting index of 3 and a range of 1. The member$ function was locating the value c as the third value in the multifield, but that value of 3 was directly returned without being adjusted for the starting index.

The code for member$ was reworked in the 6.4 release; the bug is not present in the 6.3 release. If you're only using member$ in a rule as a predicate test (either FALSE or not FALSE), then your code will work correctly because even if the wrong index is returned, the function can still be used to determine whether a value is present in a multifield. Also in the case where the multifield value is the entire slot value, the correct index will be returned.  

[denis.be...@gmail.com]

Thank you very much for your detailed answer. This allowed me to check that I wasn't concerned with the bug.