Possible problems in NAPI.C

[Mark Koennecke]

On Mon, 21 Feb 2000, Ray Osborn wrote:

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

   I tend to agree with Ray on this. That was the reason why we fixed the
   stuff in the NAPI code at all. It would have been much easier to fix
   the recent integer problem by requiring all parameters to be int32. At
   the time we decided against that in order to prevent user confusion.
   Also, with the code being as it is now, it does not matter at all what
   kind of int you pass in. 

   I feel that gcc is just picky and may even be mistaken about this
   warning. I recently ported SICS to linux in half a day and I believe 
   I created a few NeXus files from it as well. I'll check if those look
   OK. I really do wonder if our code needs to compile on all those
   compilers out there without warning.


                          Mark