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.
Rob > I think I get it: For files in the CDF-2 format, the netcdf3 api > matches what is on disk: since no dimension can be larger than 4 GB, > there is no problem using size_t for the start[] array. > > If the file is created with the NC_NETCDF4 flag, 32 bit codes are > limited by the API in what they can describe: a 4-byte size_t will > make it impossible to define a variable with a dimension greater than > 4GB. > > The only sticky area is when a 64 bit machine (AMD opteron, intel > core2) creates a NC_NETCDF4 file with big dimensions, then sends that > file to a collaborator with a 32 bit machine. In that scenario, you > just give an error, essentially saying "try again on a 64 bit > machine", right? That's what should happen, but since we don't test that scenario, I had to try it. It appears you've identified a bug, because when I try that, what gets stored as the size of a big dimension (with a size of 4500000000 that requires more than 32 bits) is silently truncated to 32 bits (it gets stored as 205032704), so it looks like the 64-bit library doesn't even store big dimensions correctly, at least on Solaris 10 xeon i86pc with Sun's cc. Then of course a 32-bit platform has no problem with that! I'll have to investigate further to make sure we're supposed to support big dimensions when using 64-bit HDF5 and netCDF-4 libraries on a 64-bit platform, in case maybe the bug is in my understanding ... --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: FFY-177157 Department: Support netCDF Priority: Normal Status: Closed