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

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

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.

  • 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