[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDF #KJU-947913]: nf90_get_att (nf_get_att_text): null characters
- Subject: [netCDF #KJU-947913]: nf90_get_att (nf_get_att_text): null characters
- Date: Tue, 28 Nov 2006 09:13:32 -0700
Ryo,
We have implemented a fix for the Fortran-90 interface for nf90_get_att_text,
to make sure the resulting string is blank-padded, and it will be in the next
netcdf-3.6.2-beta release. As I had mentioned, a corresponding fix for the
Fortran-77 interface may be impractical. This is because the Fortran-77
interface is implemented entirely in C via macros in the cfortran.h include
file, developed by a third party (Burkhard D. Burow). So there is literally no
place to insert the Fortran statement "values = ' '", and if you look at
cfortran.h, you'll understand why we are reluctant to make changes to it.
It's remarkable to me that no one has complained about his bug previously, so
thanks very much for pointing it out and explaining it. As a small token of
our appreciation, your name is now included in the netCDF Credits web page
(between two other notable contributors):
http://www.unidata.ucar.edu/software/netcdf/credits.html
As for your other suggestion to prevent overflow of a user-supplied buffer in
case the user supplies too little space for the result, that is currently a
characteristic of all the netCDF C and Fortran interfaces that read data of any
type into a user-supplied buffer. Making one interface (getting text
attributes) safer without making a similar change to all the data reading
interfaces would add an inconsistency that would complicate using and
documenting the library. Changing all the other C and Fortran reading
interfaces would at the least require new function names to preserve backward
compatibility.
But the fact that, unlike C, Fortran-90 automatically passes in array lengths
does provide an opportunity to make the interfaces safer that is currently not
being exploited. We will consider whether to make such changes just to the F90
interface, since this would not require changes to the API, just to the
implementation. So thanks for the suggestion!
--Russ
Russ Rew UCAR Unidata Program
address@hidden http://www.unidata.ucar.edu
Ticket Details
===================
Ticket ID: KJU-947913
Department: Support netCDF
Priority: High
Status: Closed