[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #KJU-947913]: nf90_get_att (nf_get_att_text): null characters

> 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