#276 conflicting clv, clr requirements, no clear range vs. gatekeeper

[David Mathog]

A frg file created by TracearchiveToCA contains an entry with these values:

clv:0,-1
clr:0,-1

which would seem to be allowed by the description here:

http://wgs-assembler.sourceforge.net/wiki/index.php/FRG_Files

1. To indicate that either the vector or quality clear range is not known, omit the clv: or clq: entry.
2. To indicate no sequence is in a clear range, any begin >= end may be used, with 0,0 being the standard. For example, "clr:0,0".

(caveat, there is a warning that isn't up to to date, but I could not find the source for what was.) Unfortunately the 0,-1 pair is toxic to the gatekeeper built from trunk on 2014_07_03 because AS_PER_gkStore_clearRange.C contains:

assert(begin <= end);
assert(begin <= fr->gkFragment_getSequenceLength());
assert(end <= fr->gkFragment_getSequenceLength());

end is unfortunately passed as a uint32, so -1 turns into 2^32-1 which is longer than the sequencelength, and gatekeeper aborts.

Either TracearchiveToCA needs to use something other than 0,-1 or gatekeeper needs to handle that end as a signed value. Or both.

[David Mathog]

Hmm, changing the 0,-1 to 0,0 or 1,1 in the input file results in the same abort. Something in gatekeeper is calculating end, setting it to -1 in these cases, and that is blowing up in AS_PER_gkStore_clearRange.C.

[David Mathog]

Amendment to the preceding. 0,-1 to 0,0 does fix THOSE entries, but it turned out there were others like 3,-1 and 5,-1, and the first one of those it hit blew up gatekeeper.

Changing all -1 to 0 in the frg file detoxified it, as far as gatekeeper was concerned.

There is a bug in gatekeeper, as far as I am concerned. If it was going to store that value into a uint32_t it should have checked that it was in range.