get_precision() walks pvalue and plvalue over the A-L and LA-LL fields,
then compares paddr->pfield against &pvalue and &plvalue -- the
addresses of the two local pointer variables, not of the fields they
point at. Those are stack addresses, so neither test has ever matched
and every A-L or LA-LL precision request falls through to
recGblGetPrec(). The line just above gets it right: prec->val is a
field and needs the &, whereas pvalue and plvalue are already pointers.
Both tests date from e87551df24, the commit that added the loop, and
have been dead ever since, so every release since R3.12 has this. They
carried a (void *) cast until 6d85a36397 removed it, which is why the
compiler was never shown a double ** to complain about. That the
fields were meant to be covered is not in doubt: this record's
get_graphic_double() and get_control_double() both name A-L and LA-LL.
This changes what those fields report. recGblGetPrec() substitutes 15
for a DOUBLE precision outside 0 to 15, so today A-L and LA-LL answer
15 for a PREC of 17 while VAL answers 17. They now answer PREC
unclamped, which is what VAL has always done.
Add selTest, reading the precision of VAL, A, L, LA, LL and HIHI from a
record with PREC=17. The four A-L and LA-LL cases report 15 before
this fix; VAL and HIHI pin the two paths either side of them.
Sang Woo Kim
ef06b34ee4