On Wed, 11 Jan 2006, David Berry wrote:
> Peter,
>
> 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
> else.
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.
|