[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 19990924: nc_inq_var of netcdf

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 19990924: nc_inq_var of netcdf
  • Date: Fri, 08 Oct 1999 08:23:52 -0600
>To: address@hidden
>From: address@hidden
>Subject: nc_inq_var of netcdf
>Organization: .
>Keywords: 199909241257.GAA06898

Thomas,

> sorry that I didn't answer earlier; I was caught by other problems.
> Thank you for your detailed answer.
> Just for your information:
> nc_type is an enum; Borland reserves only one byte for it but your library 
> assumes an integer.
> Therefore your function returns an integer where there is only one byte on 
> the stack; this overwrites varId because its address happens to be on the 
> stack near the address of the type variable.
> I could not convince the Borland compiler (bcc32.exe) to use an integer 
> size for the enum (despite the -b switch should do it and is on by 
> default).
> Therefore my solution is using an integer directly and casting this to the 
> nc_type:
>     int     type; //nc_type type;
> ...
>     err = nc_inq_var( cdfId,
>                       varId,
>                       NULL,     // name
>                       (nc_type *)&type,
>                       &dims,
>                       NULL,     // dimids
>                       NULL );   // natts
> This leaves varId unchanged.

Thanks for sending back your diagnosis of the problem.

But our library does not assume nc_type is an integer.  As far as I
can determine, it is declared with the typedef nc_type everywhere it
is used in the library source code, so it is treated consistently as
an enum (if you can find where it's treated as an int, pleas let me
know, that's a bug!).  However, whatever compiler was used to create
the DLL version of the library you are using (MS Visual C++?) may have
implemented enum as an integer.

Therefor I think the problem is an incompatibility between the
compiled DLL you are using and the Borland compiling environment you
have set up.  If you compiled the library from source with the same
compiler and flags you are using for the program that calls the
library, I would guess that you would not have to use this casting
trick, but it would work as intended.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu