Hello, This is something we can look at, absolutely; I'll need to review the code in question to see if there's a reason why it's being handled the way it is, but it might make more sense to return an error instead. Thanks for reporting this, we'll take a look. Have a great day! -Ward > Full Name: Ruurd Dorsman > Email Address: address@hidden > Organization: VORtech > Package Version: 220.127.116.11 > Operating System: Linux, Windows > Hardware: > Description of problem: > > Dear Sir/Madam, > > We are currently trying to build an application that robustly reads data > from netCDF files (in HDF5 file format). Because it is essential for > our application that it continues on errors, we have written extensive > tests. One of the tests we perform is trying to read a valid netCDF > file of which we have changed the first byte to 0x00 to mimic file > corruption. This causes the program to abort with an assertion error. > > As far as I can tell, the error is triggered by line 2866 of nc4file.c > because the variable hdf_file is zero. This variable is set in the same > file on line 294 because the function H5Fis_hdf5 recognizes the file is > not valid HDF5 and the fallback (checking the first 4 bytes of the file > for a known file format) also produces no result. > > The assertion is followed by a comment that the assert(0) should > never happen, but apparently it can sometimes occur in rare > circumstances. Replacing the line with something like: > > return NC_ENOTNC; > should fix the problem. > > Is this fix something you would be willing to include in the next release > of netCDF? > > Kind regards, > Ruurd Dorsman > > Ticket Details =================== Ticket ID: UBS-599337 Department: Support netCDF Priority: Normal Status: Closed =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.