[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 970616: MS-DOS support for netCDF
- Subject: Re: 970616: MS-DOS support for netCDF
- Date: Tue, 17 Jun 1997 17:22:26 -0600 (MDT)
> >Date: Mon, 16 Jun 1997 16:12:03 -0400 (EDT)
> >From: address@hidden
> >Organization: KEO Consultants
> >To: address@hidden
> >Subject: MS-DOS port...
> >Keywords: 199705081559.JAA25699
>
> > I hope that I am not bothering you too much, but I am getting very close to
> > successfully porting this software over to the DOS, Windows 16 bit
> > environment.
> >
> > Re: my last communication with the size_t problem. I redefined size_t in
> > your ncconfig.h file:
> >
> > typdef unsigned long size_t
> >
> > so that now the number of bytes matches your X_SIZEOF_SIZE_T variable.
>
> Hmm... Defining the "size_t" datatype should be done with careful
> consideration. It must be the same type as the argument of the malloc()
> library call, which I believe on your system is "unsigned int" rather
> than "unsigned long". Is this true?
You can't change the typedef of size_t if it exists in your compilation
environment. (That would be porting the environment to the code, not the
code to the environment.)
> > Everything now compiles without any errors, and I have actually created a
> > valid library for netCDF 3.3.
> >
> > There is one puzzling warning though...
> >
> > In line 9488 of putget.c, the return function:
> >
> > putNCvx_long_int
> >
> > is undefined. I couldn't find it anywhere in the source code.
> >
> > I was wondering if this was an error, and you actually meant that line
> > to be:
> >
> > return putNCvx_int_long
> >
> > which I noticed was defined in putget.c (line 1182).
>
> I believe you are right. The first and second "types" in the function
> name should refer to the external and internal types, respectively.
> Try changing the above function call to
>
> return putNCvx_long_int
>
> and see if things work.
>
> [Glenn -- is the above correct?]
As Cyril suggests, it should read putNCvx_int_long().
(An example of the hazards of attempting to support platforms
which one hasn't tested upon.)
-glenn