Fortran 77 Interface

[Ray Osborn]

I'm certainly not an expert on what constitutes rigorous standard-conforming
Fortran 77, but Chris is right that BYTE is not part of the standard (It's
shaded as a Digital Fortran extension in the VMS manual).  However, I
believe that neither is INTEGER*1 or LOGICAL*1 etc.  In fact, there is no
standard way of requiring 1 byte of storage for a variable.  I think we
should just choose the most commonly accepted extension and request that the
users get back to us if they have problems with compilation.

I don't think that there is a problem with internal storage, only with
passing arguments to subroutines.  For example, I was never aware of
problems with including character strings in COMMON blocks, and it seems to
be standard procedure to equivalence different length character strings.  It
must be the string elements that they line up here, not the string
descriptor.

However, it does seem clear that it is safer to provide NXputchardata
routines.

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




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