[netCDF #HNO-635604]: 64bit BE problem in netcdf-4.1.1-rc1

Howdy Mathis!

More progress to report...

> 
> The reason for tst_dims failing is almost the same as the previous error.
> In file nc4hdf.c is a sprintf which doesn't have the right format for 64
> bit. Still one check in tst_dims fails because the reference file
> ref_tst_dims.nc isn't correct.

This has now been fixed, as you know.

> 
> I'm building here with IBM's xlc and that produces more failed checks which
> all seem to be related to the fact that malloc(0) returns a NULL pointer
> for programs compiled with xlc (the standard allows that). This causes
> nc_open to fail under some circumstances. One check where this happens is
> tst_strings:
> 
> *** Testing netcdf-4 string type.
> *** testing string attribute...ok.
> *** testing string var functions...
> Sorry! Unexpected result, tst_strings.c, line: 97
> Sorry! Unexpected result, tst_strings.c, line: 98
> Sorry! Unexpected result, tst_strings.c, line: 100
> ...

I believe this malloc(0) for strings has been fixed. If you want to try the 
snapshot, let me know if it works for you.

But while fixing it I found another malloc(0) problem, which happens when a 
dimension is defined, then a data variable defined using that dimension, then a 
coordinate variable for the dimension is defined. In this case the HDF5 library 
calls a malloc with 0.

I have reported this to the HDF5 developers, and given them a test program to 
demonstrate the problem. Usually they are very responsive to any memory errors, 
so I hope to hear from them soon that this is fixed.

I am now going to check the rest of the netCDF build for malloc(0) errors.

I have added testing with the "electric fence" utility to our daily test cycle, 
so that we be sure that we don't add any errors like this in the future.

I'll let you know when HDF5 has a fix. 

Thanks,

Ed

Ticket Details
===================
Ticket ID: HNO-635604
Department: Support netCDF
Priority: Normal
Status: Open