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

Re: 950710: Netcdf c++ interface rename bug

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: 950710: Netcdf c++ interface rename bug
  • Date: Thu, 20 Jul 1995 08:38:39 -0600
Dan,

> > I think this is not a bug, because the documented specification for the
> > rename functions is that the file doesn't have to be in define mode if
> > the new name is no longer than the old name.  In this case, the new name
> > just overwrites the old name in the file header, and we don't have to go
> > through the file copying required when new space has to be allocated in
> > the header for a longer name.  It's a silly little optimization, but I
> > think the current C++ code implements it correctly.
> > 
> 
> From a "correctness" point of view, you are right,
> from a user standpoint the error case is gross, especially
> when all the other "requires define mode" functions
> do it for you automatically.
> 
> When the C++ classes get documented this should have
> a mondo warning next to it, as the failure mode is
> pretty tough to trace back to what caused it.

OK, thanks for the clarification.  I'll fix it to have the rename member
functions put the file in define mode first if the new name is longer than
the old name.

--Russ