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.
Hi Robert, My apologies for the delayed response; I've been debating how to best handle this patch offer/pull request. While it would be a useful patch, the issue at hand is that the legacy C++ API is frozen and deprecated, as you point out. The reason I am loathe to unfreeze it is because it has not been tested against any recent version of the C library; I infer that it still works, but I would not have known that without your email. Additionally, I do not want to create a new release of a library that we are actively discouraging people from using; this is why it it was not migrated to GitHub with our other projects. On the other hand, I do not want to dismiss your contribution, as it *is* appreciated. Would it be possible for you to create a patch file for your changes? It is possible that we could host that patch along side the deprecated library. Additionally, should the question arise, I would be happy to point people to your fork of the project on GitHub, if that were ok with you. Thanks for your time, have a great weekend, -Ward Ward Fisher address@hidden UCAR/Unidata - Software Engineer > Hello, > > I've added a feature to the legacy C++ API (v4.2), which I would like to > see added to a new version of that library. I know the library is frozen > and deprecated. But this is a small addition that can make a big > difference for people using code that relies on this library. > > The Problem: When NetCDF encounters an error, it prints out a simple error > message (eg: "Variable Not Found") and exits. It's hard to know which of > 100 different attempts to access a variable it crashed on. So the user > spends a lot of time tracing through the code. > > The Solution: Extend the NcError functionality so NetCDF can call a > user-supplied subroutine other than exit(), in case it wishes to exit. The > subroutine will generally be appropriate to the larger software NetCDF is > being used in. In my case, my exit subroutine causes a SEGFAULT --- which > triggers additional stuff that eventually gives me a stack trace complete > with source file names and line numbers. I can then find where things went > wrong quickly and easily. > > The (small) change to the source code is in the following github repository: > > https://github.com/citibob/netcdf-cxx > > How can this get moved along into a new version of the distribution? > > Thank you, > -- Bob > > Ticket Details =================== Ticket ID: VCN-128514 Department: Support netCDF Priority: High Status: Closed