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.
> Dear netCDF developers, Howdy Ryo! > > I'm using netcdf-3.6.0-p1 . > I think this is kind of a bug in nf90_get_att : > > character(256):: ttl > i=nf90_get_att(ncid, varid = nf90_global, name = "title", & > values = ttl) > > When the actual value is shorter than the length of the character > string ttl, the remaining part of ttl isn't modified. > > This is arguably a "wrong" behavior. In Fortran, when character > lengths mismatch, blank characters (space, \x20, or ' ') are used > as padding: > <snip> > This blank padding is universal in the Fortran world, and > many Fortran programs do depend on the behavior. > I've found a work-around, which is to fill the variable > with blanks before calling nf90_get_att. But, this isn't > what Fortran programmers expect. > Hmmm, this is very interesting. Let me ask you this: what behavior is expected in fortran 77? > I know why the current netCDF does what it does. Its Fortran > interface is mostly just a wrapper around the underlying > implementation written in C. But, I hope this difference in > character string behavior is absorbed within the wrapper. As you note, it currently is not absorbed in the wrapper. For more, see below. > > By the way, I'm worried about what happens if the length of > the character-string variable is shorter than the actual > text attribute. I haven't tried this situlation. > The canonical Fortran behavior is to truncate the input > string to the length of the receiving variable. Many programs > again depend on this behavior. (By the way, the canonical > C behavior is to overflow the variable!!) > Yes indeed! Be careful out there! ;-) I don't test this. Next time I'm working on some fortran tests I will give it a try and see what happens. (Or you could try it and let me know...) NetCDF fortran APIs work like this: The C API is wrapped in F77 functions with some header file voodoo that you probably don't even want to know about. This gives F77 function calls to the C functions. Then the F77 API is wrapped in F90 functions in the f90 directory, in the .f90 files. For example: function nf90_get_att_text(ncid, varid, name, values) integer, intent( in) :: ncid, varid character(len = *), intent( in) :: name character(len = *), intent(out) :: values integer :: nf90_get_att_text nf90_get_att_text = nf_get_att_text(ncid, varid, name, values) end function nf90_get_att_text As you can see, no checking of any kind is done - all the parameters are just passed into the F77 function, which does some voodoo and then passes them on to the C API. (The voodoo is stuff like subtracting 1 from every varid and dimid, so that fortran programmers can think they are counting starting from 1, whereas the netCDF library starts counting from 0, as a good C library should.) How would this nf90_get_att_text function know what the length of the "values" buffer? Is there a way to find this out in F90? This would be the only way for netCDF to tell whether it is about to overflow a buffer, since we don't pass the expected length of the data into the function. Thanks! Ed Ticket Details =================== Ticket ID: KJU-947913 Department: Support netCDF Priority: High Status: Open