NOTE: The netcdf-hdf
mailing list is no longer active. The list archives are made available for historical reasons.
Hi Ed, > Russ points out that my code allocates giant chunks of memory to > convert data types. I only did this because I figure you'll supplant > all this code shortly anyway. > > Presumably your code will have a reasonable memory allocation strategy, > such that you're not grabbing giant chunks of RAM, nor doing separate > small allocations millions of times. Right? Yes, we default to a 1MB buffer, but provide an API function (H5Pset_buffer) to allow user's to control the size if they'd like to adjust it. > The final work on signed vs. unsigned NC_BYTE is that, except for > range checking, we never care, and the information (i.e. whether > NC_BYTE data are signed or unsigned) is not stored in the file. The > user just has to know that for themselves. > > For the purposes of range checking, we treat all NC_BYTE data as > signed. This will result in errors when the user is actually intending > this to be unsigned data, but we can live with that. OK. I presume this is mostly an issue for the nc3 interface and that the nc4 interface may be different... Quincey
netcdf-hdf
archives: