On Wed, 11 Jan 2006, David Berry wrote:
> On Wed, 11 Jan 2006, Peter W. Draper wrote:
>> On Wed, 11 Jan 2006, David Berry wrote:
>>> This seems to be caused by CHR_CTOI happily converting a string such
>>> as "123456789123" (which represents a number which is too large for a 32
>>> bit integer) and returning -1097262461 with CSTAT == 0.
>>> Should CHR_CTOI perform a check by re-formatting the returned integer
>>> and seeing if the resulting string looks like the supplied string?
>>> A bit of a performance hit, I admit. Any other ideas?
>> My immediate thought was, how about just testing the length, say against,
>> VAL__SZI? You could avoid the overhead of fully testing long and short
>> strings that way, but that wouldn't be wonderful as you'd still need to
>> test any strings around about that length (VAL__SZI and VAL__SZI-1).
>> There's also the business of leading zeros messing things up, you'd need
>> to remove those. Maybe it would be better if you could just tell FITSMOD
>> what format to use!
> I think fixing the root cause (i.e. CHR_CTOI rather than FITSMOD) would be
> better since it will ensure the problem does not cause trouble anywhere
Well, good luck, hope the inefficiencies are not too high (I'd guess these
are most likely to effect the catalogue reading used in CAT and GAIA) and
having a bad status return, that works, doesn't bite.