I've finished the MERS rewrite in the sense that all the fortran that
can be converted to C has been converted to C. The MSG_FMTx functions
are annoying since there is no way to rewrite them but on the plus
side I don't think the C msgFmtx routines should be calling them (they
should be calling C versions). Of course one option is to insist that
MSG_FMTx uses C formatting and patch all the code in the repository
accordingly....
EMS has been tweaked so that a C pointer in emsSetc is formatted as
<Null> and not a blank string. I've also had a stab at varargs support
for emsRep and emsSetc and whilst it all works fine the downside is
that '%' becomes a special escape character in EMS in addition to
'^' (so KAPPA STATS gets upset). The issue is that there is no way to
know how many optional args were given to emsRep so no way to know
whether sprintf replacement should be done. That is, unless I start
parsing the string to decide whether any arguments are expected to be
processed (do I just look for % and if it is followed by an
alphanumeric assume it is being expanded else escape it with %%)?
Looking through the code there aren't many occurrences of '%' in
tokens or message strings and all the ones I have found that have %
followed by alphanumeric would be replaced by MERS escape handling.
I've also come to the conclusion that msgSetc can't pass its va_list
to emsSetc intact and I either need to
#define msgSetc emsSetc
or provide an additional interface to ems for va_list processing
void emsSetv( const char * token, const char * message, va_list
args );
(similarly for errRep and emsRep). Any thoughts? Or should there be a
whole new API for emsRep and emsSetc variants that take optional args?
--
Tim Jenness
Joint Astronomy Centre
|