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.
Hi Steve, > I'm not a heavy netcdf user (although I'm writing some netcdf code > for reading LAPS output files) but I maintain the netcdf ebuild for > Gentoo, as well as build rpms for RedHat/fedora/cAos, etc. > > The netcdf rpm I built recently on RHAS 2.1 (which still uses gcc > 2.9.6) seemed to build fine, and I didn't notice any warnings like > below, however, when updating the netcdf ebuild on Gentoo, I saw a > slew of warnings druing the fortran test. > > My current Gentoo desktop has gcc 3.3.3 and g77 (no f90 compiler), > with some of the output pasted below: ... > ftest.F:187: warning: > call ncagt (outcdf, NCBYTE, attnam, bytval, iret) > 1 > ftest.F:196: (continued): > call ncagt (outcdf, NCGLOBAL, attnam, shval, iret) > 2 > Argument #4 of `ncagt' is one precision at (2) but is some other > precision at (1) [info -f g77 M GLOBALS] ftest.F:187: warning: > call ncagt (outcdf, NCBYTE, attnam, bytval, iret) > 1 > ftest.F:198: (continued): > call ncagt (outcdf, NCGLOBAL, attnam, lngval, iret) > 2 > Argument #4 of `ncagt' is one precision at (2) but is some other > precision at (1) [info -f g77 M GLOBALS] ... > It seems like type/precision errors might cause a problem at some > point, but what do I know? Maybe they're benign... I think these are benign and unavoidable with the netCDF-2 interface in Fortran77, which is what this is testing. The netCDF-2 interface was the early Fortran interface that used the same parameter for data of multiple types: SUBROUTINE NCAGT (INTEGER NCID, INTEGER VARID, + CHARACTER*(*) ATTNAM, type VALUES, + INTEGER RCODE) where VALUES Returned attribute values. All elements of the vector of attribute values are returned, so you must provide enough space to hold them. If you don't know how much space to reserve, call NCAINQ first to find out the length of the attribute. Warning: neither the compiler nor the netCDF software can detect if the wrong type of data is used. was a container for any numeric type of values (INTEGER, REAL, DOUBLEPRECISION, ...), using knowledge that Fortran argument passing is by address. The equivalent C argument would be a void*. The later netCDF-3 interface employed type-safe interfaces for Fortran by using lots more functions, but we still want to support the old netCDF-2 interfaces forever, and there is no way to test such interfaces without violating picky compiler rules about types always matching on different calls to the same function. > PS. I'll test it with gcc 3.4 and see what happens, and the next > version after 3.4 should have gfortran. I suspect these potential errors will still be reported, since being loose with types as in these tests is often a symptom of an error, but not in this case ... --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu/staff/russ