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

Re: Doc errors in C++ interface

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: Doc errors in C++ interface
  • Date: Mon, 17 Nov 1997 10:06:43 -0700
> From: Michael McCarrick <address@hidden>
> Subject: Doc errors in C++ interface
> To: address@hidden

Hi Mike,

> I have found two documentation errors in the netcdf C++ interface.
> I am using release 3.3.1 on various platforms. First, in the NcTyped 
> class (as well as the NcVar and NcAtt derived classes) the 
> NcValues* values() member function documentation says:
> 
>         Returns a pointer to the block of all values for the variable 
>         or attribute. This will be deleted when the variable or
>         attribute is destroyed.
> 
> This is not true.  The allocated buffer is never deleted and leads to
> significant memory leaks. The caller must delete this NcValues pointer
> explicitly.

Thanks for pointing out the problem.

We were relying on the "purify" tool to tell us about memory leaks, but
when run with our small C++ test case, it says there are no memory
leaks.  Our test is just inadequate for this purpose.

Looking at the code, it's obvious that you're right.  I've corrected the
documentation.

> Second, the NcAtt member function long num_vals() documentation says:
> 
>         ... and the number of characters (including the terminating
>         '\0' character) for a string-valued attribute.
> 
> Again, this is not true. The return value is just strlen(str_attr),
> i.e., not including the terminating null.

Right again.  Thanks for pointing out the problem.

> And finally, there is a problem compiling on SunOS 4.x.  This os lacks
> the memmove() system call, but has bcopy().  A simple def like:
> 
> #if defined(__sun__) && !defined(__svr4__)
> #define memmove(dest, src, n)  bcopy((src),(dest),(n))
> #endif
> 
> in libsrc/ncio.h or elsewhere takes care of the problem.  Configure
> could probably be set up to handle this automatically.

It compiled fine on our SunOS 4.1.3 and 4.1.4 platforms, which have the
memmove() call available when <string.h> is #included and the Sun acc
compiler is used.  Maybe you were using the old BSD compiler?

> Mike McCarrick

Thanks again for reporting the bugs.

--Russ

_____________________________________________________________________

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