Bug in NAPI...

[Brian Tieman]

Hi all,

I think I found a bug in NAPI as well as a few confusing
inconsistancies.

I've been trying to use NXgetslab and everything was working fine until
I tried to read a subarray out of a 2D data set where the start index
was not 0.  This caused my program to crash at the line

    SDreaddata (pFile->iCurrentSDS, (int32*)iStart, NULL, (int32*)iSize,
data);

in

  NXstatus  NXgetslab (NXhandle fid, void *data, int new_iStart[], int
new_iSize[])

As long as I used a start index of 0 for both dimensions, everything
appeared to be working OK.  When I tried any other start index, the
program would crash.

Looking at the code in NAPI, it turns out that NXgetslab is recieving
iStart and iSize as int and then typecasting them to int32 in the call
to SDreaddata.  This is what was causing the problem on my machine.  I'm
building on a Windows PC and my native int size is 16 bit.  It looks as
though the cast to int32 picked up garbage high bits which probably
caused overrun errors in the HDF code.

That's my guess anyway because doing an explicit assignment of iStart to
a new variable of type int32 and then passing that variable fixed the
problem.  Is it possible to quickly fix this in the official release?

Also, looking at the code, I had to wonder about a couple of things.
One is that the documentation says that NXgetslab expects start and end
indices, but the NXgetslab prototype expects iStart and iSize not iEnd.
I origionally thought this was my problem until I looked up how
SDreaddata is supposed to work.  Two, should all the NAPI calls be using
an explicit sized integer for parameter passing?  SDreaddata needs
int32, but the prototype allows for int--which is machine dependant and
how I got into trouble in the first place.

Just some thoughts...

Brian Tieman
tieman at aps.anl.gov