Print

---

2008/9/16 Tim Jenness <[log in to unmask]>:
> 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
> %%)?

Aren't there cases of % in printf formats that are *not* followed by
alphanumerics?  E.g. "%*s", "%.*g", etc.

> 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.

Given the low existing usage of the MERS "%" escape character, I think
I would be tempted to do away with it. That is, remove the few
occurrences of "%" in the repository, and add a warning to the release
notes for the next release.

> 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?

AST goes to significant lengths to handle variable argument lists. If
ems had an internal function

   emsVSetc( const char *token, const char *value, va_list args );

then the public emsSetc function could be just:

void emsSetc( const char *token, const char *value, ... ){
      va_list args;
      va_start( args, value );
      emsVSetc( token, value, args );
      va_end( args );
}

and the msgSetc function could similarly invoke emsVSetc instead of
emsSetc. Within emsVSetc you use vsprintf to substitute values into
the supplied message:

   char buffer[ MAX_MESSAGE_LENGTH ]
   nc = vsprintf( buffer, message, args );

David