> HDS and PRIMDAT explicitly agree on the definition of bad values without HDS
> depending on primdat (I think there is even a test for it).
> HDS doesn't use VAL__BAD but it does use an internal global struct that
> defines the bad values for its own use. These are the values that are
> inserted when conversion fails so HDS does actually use bad values for the
> conversion as you state above AND they are assumed to be PRIMDAT equivalent.
Well you wouldn't want two sets of bad values. We didn't pick vlaues
at random.
SSN/27 only talks about using these bad values for conversion errors.
However, in a footnote William does remark that the conversion routines
are unsatisfactory: "a bad value will not be converted to a bad
value[...]"
> So I think the feature-not-bug case is that someone using HDS has to worry
> that the bad value definition in HDS is not defined and its only when
> Starlink applications use HDS that the Starlink definition of bad value
> becomes relevant.
Yes. The programmer manual SUN/92 makes no mention that an object's
value is restricted to exclude special bad values. It's not
inconceivable that there are existing HDS data that use the full dynamic
range of say _UWORD. Changing HDS will then make some good values bad.
> The problem is that if I map _INTEGER as a smaller type and _INTEGER has bad
> values in it then I'm guranteed to get a conversion error but I can't really
> tell whether it's an error I should be worried about or simply a bad value
> (which is guaranteed to be out of range of the smaller type).
>
> So my choices are:
>
> 1. Map as _INTEGER and write my own conversion code (using VEC but with a
> C interface)
That's what I'd prefer.
> 2. Assume that DAT__CONER errors can be ignored when I map a smaller type
> (effectively assuming that conversion errors are occurring because of
> bad values rather than unexpected out of range values). Note that
> these will contain perfectly valid PRIMDAT bad values.
If you know for your data that DAT__CONER will _always_ be bad values,
yes you could peek around the curtain.
> 3. Add one if statement to HDS for the conversion error handling
>
> #3 seems safest to me (even if I have to add that one line in quite a few
> places). #3 does not cover the case where you are mapping to a bigger type
> since there is no overflow handling code in there so I'd have to add many
> cases.
It's still 8!/6!2! = 28 if you include _CHAR.
Malcolm
|