What to do about int's

Ray Osborn ROsborn at anl.gov
Mon Feb 14 21:38:35 GMT 2000


on 2000/02/14 9:49 AM, Mark Koennecke at Mark.Koennecke at psi.ch wrote:

>> 3) Do people agree with my comment last week that it is necessary to support
>> 16-bit int's?
> 
> Well, 16-bit int is dying but may be we get 64-bit int some day
> soon..... But as 16 bit is rare and Brian seems to have solved his
> problem I do not think that we need to hurry.
> 
>> 
>> 4) If so, what should our policy be?  It shouldn't take long to clear things
>> up in NAPI.C.  What we do depends on the answer to the above questions.  For
>> example, we could typecast scalars (passed by value) to HDF calls, but copy
>> all the rest into local int32 variables.  I certainly don't believe that we
>> should suddenly ask everyone who uses NAPI to rewrite their programs
>> converting all int's to int32's, unless someone can convince me it's really
>> necessary.
> 
> I think your idea of doing the necessary typecasts within the NAPI
> functions is the right solution.
> 
>> 

Thanks for the replies.  The consensus (out of three of us) seems to be what
Mark just wrote - we typecast local variables when necessary.

I agree that the urgency may have gone out of this problem.  I would like to
suggest that, over the next few weeks, Mark and Freddie gradually fix those
cases where they see int's being passed to HDF i.e. when you have time,
correct an occurrence in NAPI.C and update the CVS server.  There can't be
more than perhaps ten corrections to make.  When we're done, I will release
v 1.3.2.  I guess we should try and test that the fixes work, so I'll try
and break the current system by compiling a program with 16-bit int's.

Thanks,
Ray
P.S. I would also propose that we keep an eye out for other possible type
problems - e.g. are we using size_t or NXstatus typedefs when we should be?

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