Re: important implementation note for range checking and type conversion...

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...


  • 2003 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-hdf archives: