Re: Question about possible error in netCDF manual

Hi Don,

This is to acknowledge that you were actually right in the appended
message that you sent on 20 April, 1994!  We recently got another
similar report and investigated the problem more fully.  This time we
discovered that the documentation error you originally pointed out
applied for attributes that were written without a trailing null byte,
e.g. from FORTRAN or ncgen.  The reason we originally couldn't duplicate
the problem in a test case is that we were writing the attribute with a
trailing null byte, so it was naturally being returned with that
trailing null byte.

The problem is more fully explained at 

  http://www.unidata.ucar.edu/packages/netcdf/known_problems.html#ncattinq-doc

in our "Known Problems with the netCDF Distribution".

I'm sorry we didn't investigate your original bug report more carefully.
Anyway, better late than never, I hope!  A belated thanks for the bug
report.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu

From address@hidden Wed Apr 20 06:38:14 1994
Message-Id: <address@hidden>
Full-Name: Russ Rew
To: address@hidden (Don Hooper)
Subject: Re: Question about possible error in netCDF manual 
In-Reply-To: Your message of "Wed, 20 Apr 1994 11:49:01 +0700."              
<9404201749.AA14557@canth> 
Organization: UCAR Unidata Program
Date: Wed, 20 Apr 1994 12:38:14 -0600
From: Russ Rew <address@hidden>

> Organization: NOAA/CDC
> Keywords: 199404201748.AA15020

Hi Don,

>       My name is Don Hooper.  I work for NOAA's Climate Diagnostics
> Center.  I've been working on some netCDF applications, and I'm
> thinking I may have come across an error in the documentation for
> the ncattinq function.  The manual for version 2.3 states that,
> for character type attributes, the length returned is one plus the
> length of the string, as the null is stored.
> 
> I use a couple of attributes whose values take the form
> "yyyy-mm-dd hh:mm:ss".  I count the length of that string as 19, and
> when I create my netCDF files, I set the length of the attribute to
> 20 when I call ncattput, as the manual states to count the null.  Yet,
> when in another program that reads this netCDF file I call ncattinq on
> this attribute, it returns 19 for the length.
> 
> I don't see a problem with the netCDF library either counting the
> null or not counting it, as long as it's consistent between
> ncattput and ncattinq, and the documentation accurately reflects
> the actual convention.
> 
> It is, of course, possible that I'm in error about my facts.  I just
> thought I'd ask if this was a known problem with the documentation.
> Thanks very much for your time.

I can't duplicate the problem here.  I just compiled and ran the following
program linked against the netcdf library:

-------------------------------------------------- cut here -----------------
#include <stdio.h>
#include "netcdf.h"

main() {
    int ncid, len;

    ncid = nccreate("atlen.nc", NC_CLOBBER);
    ncattput(ncid, NC_GLOBAL, "title", NC_CHAR, 10, "The title");
    /* Get the length of the attribute that was just stored */
    ncattinq(ncid, NC_GLOBAL, "title", (nc_type *)0, &len);
    ncclose(ncid);

    printf("Should be 10: %d\n", len);
}
-------------------------------------------------- cut here -----------------

and the result of running the program was:

        Should be 10: 10

as expected.  If you could supply a small example program that demonstrates
the problem you described, I could see if we can duplicate it and determine
whether there is a bug.  The documentation says the extra NULL should be
counted both for the ncattput() and ncattinq() calls, so If the library
isn't behaving this way, it is definitely a bug.

__________________________________________________________________________
                      
Russ Rew                                              UCAR Unidata Program
address@hidden                                        P.O. Box 3000
(303)497-8645                                 Boulder, Colorado 80307-3000