bufr_subset_find_values() fails when TLC keys are used

[vsouvan]

Testing with the following template:

201013 201023 5012 101003 12001

Shows that if I do a find using a TLC code, ala:

     k = 0;
     bufr_set_key_location( &(codes[k++]), 5002, 64 );
     bufr_set_key_int32( &(codes[k++]), 12001, NULL, 0 );
     n = bufr_subset_find_values( dss, codes, k, 0 );

I get the wrong instance of 12001. The bug appears to be that in bufr_subset_find_values(), a TLC match still increments to the NEXT descriptor in the list, and because that descriptor is replicated, I get it instead of the one which had the matching TLC value.

I'll commit a test case...

---

Imported from Launchpad using lp2gh.

• date created: 2011-11-17T18:52:21Z
• owner: chris-beauregard
• assignee: chris-beauregard
• the launchpad url was https://bugs.launchpad.net/bugs/891754

[vsouvan]

(by chris-beauregard)
Ah... another bug is that:

     k = 0;
     ivalues[0] = 291;
     bufr_set_key_int32( &(codes[k++]), 12001, ivalues, 1 );

     n = bufr_subset_find_values( dss, codes, k, 0 );

Gives me the first 12001 descriptor in the sequence, because when we match descriptors but not the value, we don't reset the jj index. Which means we don't set it to the actual match.