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

Re: Questions about netCDF 2.4 plans

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