Possible problems in NAPI.C

[Ray Osborn]

on 2000/02/21 11:39 AM, F.A.Akeroyd at rl.ac.uk at F.A.Akeroyd at rl.ac.uk wrote:

> Ray,
> 
> i think that is probably caused by "int32" being defined as "long"
> rather than as "int" on some systems (but always as a 32 bit sized value);
> even if "long" and "int" are the same size, they are not classed as the same
> type by the compiler and hence a warning is issued about (int*) being
> cast to (long*). 

That seems to be right.  In fact, the Metrowerks compiler gave exactly that
error message (something like "can't cast int to long").

> We could remove the warning by putting an (int32*) cast on
> the line; however i wonder if it would be better to change the definition of
> NXputslab and NXgetslab to take "int32*" rather than "int*"? I don't think
> it would
> cause a problem for most people's code (at worse they would get the same
> warning you
> just had, but if the code worked before the change it would still work after
> it)

I've checked that casting the iStart and iSize arrays to int32 removes the
problem.  

What would be the advantage of changing the NAPI function arguments to
int32?  You have already done most of the hard work in checking for size
problems.  If the remaining problem is solved by adding a simple typecast to
the one function call, then I'm against changing all the documentation in
order to introduce a new variable type.  I believe that I'm right in saying
that all the functions in the C API only require int's, and should now work
without problem (assuming 16-bit integers are large enough for what they
contain).  Why confuse users by introducing int32's at this stage?

> 
> Also, i wonder if the FORTRAN interface needs a look ... i believe it passes
> INTEGER types to NXputslab etc, but if a C integer is 16bit is a FORTRAN
> INTEGER also 16bit? If we changed the C interface to be "int32*" then
> you could make things safe by forcing FORTRAN to send 32bit integers using
> some modern
> equivalent of "INTEGER*4" (is it selected_int_kind()?)
> 

You can declare a variable to be

   integer(kind=NXi4) :: iStart(NX_MAXDIMS)

to attempt to get the right size in Fortran 90 (NXi4 is a parameter defined
in NXmodule.f90).  In Fortran 77, INTEGER*2 etc. are really non-standard
(though nearly universal) extensions.  Fortran is designed for numerical
computation where you specify the precision your calculations require, but
leave the internal details of how you get it to the compiler.  There are
standard F90 routines that tell you what length the integers are, but no way
of guaranteeing a particular length in advance.  This is only a problem when
interacting with other languages, and I think INTEGER's should be equivalent
to int's if the C and Fortran compilers come from the same vendor (whether
g77/gcc, Absoft, Compaq etc).  We can then trust the solutions you and Mark
have already implemented in NAPI.C.

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