Re: PREC

[Andrew Johnson <anj@aps.anl.gov>]

Pete R Jemian wrote:
> But someone can always come up with a standard situation where
> a single format specifier for all fields is problematic.
> How can we handle some fields differently from others?

This can already be done for the precision value, if it is implemented in 
the record support code - there is no requirement that there be just one 
field for setting precision, but I'm not aware of any records that have 
more than one; many record types don't have a PREC field at all.  There's 
nothing stopping something like the motor record from providing a 
different precision for some fields than it does for others.  Here's how:

There is a routine in the record support, called get_precision() which is 
responsible for returning the precision value for any record field.  Most 
record types just check if the field they're being asked about is VAL and 
if it is they return PREC; if not they just ask recGblGetPrec() which sets 
a default for the particular field type.  Any record that needs multiple 
precision settings can just test for multiple field addresses and return 
different precision values as it sees appropriate - presumably it would 
group different fields together and have a precision field for each group.

I agree that Stephanie's .FMT would be a nice idea if we were starting 
from scratch, but right now we would have to replace the numeric precision 
field that currently exists in all of the struct dbr_gr_<xxx> definitions 
in cadef.h and we'd have to modify the CA protocol and all of the clients 
that use it.  In the future we'll be able to do that if we decide it's the 
best solution, but I can't really see us moving away from a single number 
defining precision for quite a while.

We already have an implementation that copes with multiple fields if we 
can agree to redefine what the precision value actually means.  It would 
probably be simplest and best for the next major release branch (R3.15) to 
change the definition of precision to be that of the ANSI C standard's %g 
format string - does anyone particularly object to that idea?

- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro