Fortran 77 Interface

C.M.Moreton-Smith at rl.ac.uk C.M.Moreton-Smith at rl.ac.uk
Tue Sep 21 09:09:36 BST 1999


It occurs to me that I'm not sure BYTE or INTEGER*1 are actually standard
FORTRAN-77 but I'm happy to be corrected, there is also a question about
what equivalencing a CHARACTER* variable to another type actually gives, it
might just equivalence the start of the data structure in which a character
string is stored, not necessarily the same as the string itself - does
anyone know if the operation we expect is actually standardarised in
FORTRAN-77?

Anyway, if there's an ambiguity I'd suggest that we provide option (1) as it
makes the intent clear.  Using NXputdata for characters stored in an array
of another type e.g. LOGICAL is just taking the FORTRAN-66 approach and
needs to work OK if this is how the user chooses to do it.

Chris


--
Chris Moreton-Smith, Software Development Manager
ISIS Science Instrumentation, CCLRC, Chilton, Didcot, OXON OX11 0QX
Telephone: +44 (0) 1235 446544, Fax: +44 (0) 1235 445720
Email: C.Moreton-Smith at rl.ac.uk


> -----Original Message-----
> From: Ray Osborn [mailto:ROsborn at anl.gov]
> Sent: 20 September 1999 23:07
> To: NAPI at isise.rl.ac.uk
> Subject: Re: Fortran 77 Interface
> 
> 
> I would support Freddie's suggestion of providing both 
> methods.  The only 
> other drawback of using the EQUIVALENCE method that occurred 
> to me was that
> the user can't put the value directly in the function call e.g.
> 
>       status = NXputdata (fileid,'NeXus data')
> 
> would not work.  If we informed users that they could either 
> use NXputdata,
> with equivalenced integer*1 arrays, or NXputchardata, with 
> character data,
> then we can leave it to the user which they prefer.
> 
> I'm against using CFORTRAN since it adds a whole new layer of 
> complexity to
> Fortran code installation.  It seems to me that Freddie has 
> already solved
> most of the portability issues with his Fortran 77 interface 
> and CFORTRAN
> will only add more headaches.
> 
> Can we take a vote on either of the two options :
> 
> 1) Provide both NXputdata and NXputchardata explaining how 
> the user can use
> either for character data.
> 
> 2) Provide only NXputdata, and ask the user to equivalence 
> character strings
> to a INTEGER*1 or BYTE array.
> 
> Ray
> --
> Dr Ray Osborn                Tel: +1 (630) 252-9011
> Materials Science Division   Fax: +1 (630) 252-7777
> Argonne National Laboratory  E-mail: ROsborn at anl.gov
> Argonne, IL 60439-4845
> 
> 
> 
> 
> > We could provide both ways of doing things e.g. a user can call
> > "nxputattr" and "nxputdata" with character types after doing an
> > equivalence, or they can call "nxputcharattr" and 
> "nxputchardata" etc. if
> > they would rather not. If they use f90, they do not need to 
> be concerned
> > with this as the "function overloading" will match up the correct
> > function call for them.
> >
> > Freddie
> >
> > On Fri, 17 Sep 1999, Ray Osborn wrote:
> >
> >> Freddie had made the suggestion that we should require the user to
> >> equivalence any character string to an integer*1 (or BYTE) 
> array, which
> >> he/she then uses as the NXputdata/NXgetdata argument etc. 
> I've just checked
> >> that this works fine on our Alpha/VMS system, even without 
> making any
> >> arrangements to null-terminate the passed array.  I don't 
> think that this is
> >> because VMS Fortran initializes all arrays as 0 since I 
> used the same buffer
> >> more than once, the second time with a shorter string.  
> The second time, the
> >> buffer would have been padded with spaces.
> >>
> >> My tentative conclusion is that Freddie is right that null 
> termination is
> >> not required here because we only pass the array to and 
> from HDF with a
> >> defined length.  In other words, we don't even have to modify
> >> NXputdata/NXgetdata to cope with NX_CHAR datatypes.  This 
> would satisfy
> >> Mark's preference to have the same interface for C and F77 
> interfaces.
> >>
> >> It does require that the user use EQUIVALENCE statements 
> but this is fairly
> >> easy to explain.
> >>
> >> Any more opinions?
> >>
> >> Ray
> >> --
> >> Dr Ray Osborn                Tel: +1 (630) 252-9011
> >> Materials Science Division   Fax: +1 (630) 252-7777
> >> Argonne National Laboratory  E-mail: ROsborn at anl.gov
> >> Argonne, IL 60439-4845
> >>
> >>
> 



More information about the NeXus-developers mailing list