On Thu, 21 Jul 2005, Norman Gray wrote:
> On 2005 Jul 21 , at 13.19, Peter W. Draper wrote:
>
> > I'm playing around with gfortran and g95, just to see how bad things
> > really are (quite is the quick answer), and came across a problem with
> > setting the VAL__BADD value. There's currently no recognisable HEX
> > format (they use X'...' or Z'...' not our '...'X, but these BOZ
> > constants aren't allowed for anything other than INTEGERs anyway...)
>
> I can't remember if we've thought of this and excluded it, but can't
> this be done using EQUIVALENCE? I don't think we did, because the
> only stardev discussion mentioning EQUIVALENCE is in connection with
> the '\\' problem, which you described a gordian-knot-cutting solution
> for. This sort of thing _is_, after all, what EQUIVALENCE is for.
> But it won't work, I think, because isn't EQUIVALENCE removed from f95?
EQUIVALENCE is still alive, just not recommended, so it is OK to use, but
I don't think it'll help here. You cannot equivalence PARAMETERs as that
would break their readonly status, so we'd need EQUIVALENCES with
initialising DATA statements. That would introduce the need for another
include file in addition to PRM_PAR.
> Is the BOZ test inline in configure.ac still adequate, or should I
> extend it to detect Z"..." as well?
Well it correctly determined that our BOZ declarations are not supported!
Unfortunately they are also used in other packages (FIGARO and CAT come
immediately to mind, CAT because it uses a BOZ assignment to a LOGICAL
parameter to determine a third NULL value for LOGICAL types), so all those
would need to be converted into configurable or preprocessable form.
Strictly we'd also need to differentiate between integer and floating
point parameters, so that takes us back to the first point.
There are plenty of other killer gfortran/g95 issues (like no BYTE
support), so none of this looks very urgent and will take a long time to
sort out.
Cheers,
Peter.
|