Re: NSPredicate bug (Re: Using code from Cocotron)

[Fred Kiefer]

Yen-Ju Chen wrote:
> On 5/23/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
>> Triggered by this mail, I set down and wrote some code for NSPredicate
>> and NSExpression to make these classes (and their subclasses) at least
>> usable. They are still far away from being complete, but it would be
>> nice if somebody actually tested them. The best thing to do now is write
>> some test code, exercising these classes and integrate that into our
>> test framework.
>> I promise to have a look at the bugs found in that process.
> 
>  I write some simple tests with UnitKit.
>  All tests pass on Mac, but have problem with GNUstep.
>  I think it is due to predicate parsing.
>  The test is attached.

Thank you for the test. It took me some time to get it running as the
UnitKit in Etoile does not compile properly. You need to install the
Framework frist and then you are able to compile the run script. Looks
like who ever wrote the makefile for this framework never tested it on a
clean system.

After hacking in some debug output into NSPredicate it became obvious
that simple lines like the following break the parser:

p = [NSPredicate predicateWithFormat: @"%K == %d", @"Record1.Age", 34];

Here we have an integer parameter that needs to be parsed and the code
in parseSimpleExpression is not prepared to do so. But this also raises
a deeper problem. The nextArg method on GSPredicateScanner expects all
the arguments in the varg list to be of type id. When this isn't true
the repeated loop over the arguments may produce nonsense. Now this is a
problem I cannot resolve myself. Perhaps Richard has an idea here?

I remember we had problems with that va_list structure, when I
introduced it and I still don't have a glue how this works internally.

There are plenty of other problems with predicates that your tests
uncovered. For example we don't support "==", but have "=". Which of
them should we have? Both?
Also the "IN" operator will only work for strings, not for a set and an
element.
Handling of "BETWEEN" is completely missing and the parsing of all key
words failed at the end of the string.

I tried to fix some of this, but it requires a lot more work.

Cheers,
Fred