On Mon, 15 Sep 2008, Tim Jenness wrote:
> 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.
Isn't the special use of '%' that we have already in parameter references
also an issue? The old:
CALL MSG_OUT( 'ET_RANGE', '%ET parameter is ignored.', STATUS )
we were discussing the other day. Disentangling them from format
statements must be messy.
> 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?
I'd vote for the latter, just to keep some stability in the API.
Peter.
|