Bug in NAPI...

[Brian Tieman]

Mark,

I'm developing on Win95/98/NT and on all three platforms, ints are supposed to
be 32 bit.  Also, I've never had a problem with this before.

So, I looked into the problem further and I think there may be a bug in my
compiler (Inprise's CBuilder).  CBuilder will still build 16 bit code if
requested (16 bit code will still run on 95/98 in most cases) although I've
never intentionally tried it.  Doing some further tests today, I've been
unable to recreate the problem under any circumstance.  My guess is something
confused my compiler to start generating 16 bit code which caused the problem
to surface.

Brian

Mark Koennecke wrote:

> On Wed, 9 Feb 2000, Brian Tieman wrote:
>
> > 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.
> >
>   You are right, this is a bug. Should we go for an own NXint32 or the HDF
>   int32 for the arguments in order to fix it? It ocurred to no one so far
>   that there might be 16-bit ints as default still out there. What was
>   that environment exactly? Win32?
>
>                       Mark