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 Mike, > We are getting ready to do a beta release of a new version of HDF (HDF > 4.0), and have a few questions about the netCDF source code, related mainly > to what your plans might be for the 2.4 release. > > Error-handling > -------------- > We are trying to unify our error-handling methods as much as possible. We > have found a number of "printf" statements in error-reporting situations in > the Unidata netCDF code, which causes some problems for some users' > programs. We would like to replace these with error handling that just > returns values, but we don't want to change the Unidata code any more than > necessary, so we were wondering... > > - Are there there are any plans in netCDF 2.4 to change the > way the netCDF library handles errors. I've just looked through the library sources and the only occurrences I can find of printf calls are in debugging code that is not compiled by default (e.g. it is guarded by "#ifdef VDEBUG" or something similar), or in error.c where the code to print error messages is isolated under the nc_serror() or nc_advise() interfaces. If any call to printf() occurs when the user has set the error-handling flags to non-verbose, that is a bug. If you can tell us how to demonstrate this bug, we'll fix it in netCDF 2.4. Other than that, we hadn't planned to change the error handling in netCDF 2.4. We will eventually have to set error handling options for the C interface with a function instead of a global variable (as we already do for the Fortran interface), in order to make the netCDF library thread-safe, but that probably won't happen until netCDF 3.0. > ANSI code > --------- > Our next version of HDF will be ANSI-C only--i.e. no K&R C. This leads to > a couple of questions: > > - Would you anticipate any problems mixing our ANSI code with the > netCDF (non-ANSI) code? No, we are making sure the netCDF code works OK on pure ANSI compilers, such as Sun's ANSI C compiler with the "-Xa" option. > - Are there any plans for an all-ANSI version of netCDF? Yes, I would call netCDF 2.4 an all-ANSI version if it compiles and runs with no errors using a atrict ANSI compiler, and that's already done. Of course the "configure" script we use to create the Makefiles adapts to systems that don't have ANSI environments, so it will work OK in those environments also. > A final question, so that we can decide whether to make changes now or > later to the netCDF library: > > - Do you have an estimated time when the version 2.4 > of the netCDF library will be released? Unfortunately, we're depending on getting some changes that we aren't responsible for (Cray optimizations) and we don't know yet what kind of effort will be involved in integrating those into our master sources, but we've been promised that we'll see them soon. Another source of uncertainty is how long it will take to make sure the current distribution builds and test OK on VMS and MS-DOS, two systems we hardly ever deal with except when testing netCDF releases. While testing the last release, a stubborn bug in the MS-DOS port took 2 weeks to find and fix. But I'm hoping we'll have a beta release ready for testing in June. --Russ