On Sep 16, 2008, at 6:43 AM, Peter W. Draper wrote:
> On Mon, 15 Sep 2008, Tim Jenness wrote:
>>
>> 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.
>
Yes. I'm annoyed but the fact that % is an escape in MERS means that %
is not allowed to also be an escape in EMS. The main problem is "%s"
becomes "%<s>" after MERS processing which gets mangled to random
badness by EMS. The solutions are:
1. Use a different escape character in MERS (can't be that many
msgOut and errRep entries to change)
2. Handle % like ^. errRep knows that ^^ will be converted to ^ by
msg1Form and so reverts it back to
^^ before calling emsRep. errRep could also convert %<xxxxx> back
to %xxxxx and % back to %%
(which would require changes to msg1Form_stand to make sure it
fiddles with % in a similar way
to msg1Form_adam)
Granted this is painful. msgSetc does not have that problem because
tokens are inserted by EMS not by MERS and that happens after MERS
escape handling. There is a compatibility problem in that any random
text string being passed to msgSetc needs to be careful to have %% used.
So I think I have no choice but to add msgVSet, emsVSet and emsVRep to
the API and leave the others as they are.
>> 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.
Scaredy cat :-) But given that we are intending to make a release in a
month and I'm getting on a plane in 3 days I suppose that is the right
way to go...
--
Tim Jenness
Joint Astronomy Centre
|