[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDF #YHC-662367]: nc_inq_grpname documentation bugs
- Subject: [netCDF #YHC-662367]: nc_inq_grpname documentation bugs
- Date: Sun, 05 Oct 2008 07:06:59 -0600
> > Hi,
> >
> > I'm trying to understand how netcdf-4 works by consulting the
> > documentation, but there seem to be some places where it's at odds with
> > what the library actually does.
>
> Whoops! Sorry about that!
>
> >
> > For example, I'm working on groups at the moment. The documentation for
> > nc_inq_grpname_len says that the name of the root group is "/", but the
> > documentation for nc_inq_grpname says that the name of the root group is
> > "". The library itself seems to return "/", so presumably the
> > documentation for nc_inq_grpname is mistaken in this. (By the way,
> > nc_inq_grpname_len returns a length of 1 for the length of the root group
> > name, but nc_inq_grpname touches 2 entries of the character array it is
> > passed, since it appends a NULL character. That's not entirely unexpected
> > for a C programmer, but I think it's worth a mention in the documentation
> > that the length returned by nc_inq_grpname_len is not as long as the
> > string affected by nc_inq_grpname.)
OK, I have fixed the C documentation concerning this. The missing piece of the
puzzle for you is the
nc_inq_grpname_full function, which returns the fully-qualified name.
For nc_inq_grpname, the name is going to be NC_MAX_NAME + 1, or less.
> >
> > Another issue is that nc_inq_grpname clearly says that it returns what you
> > might call the "fully qualified" group name, i.e.,
> > "group1/subgrp1/subsubgrp1", but when I run test programs I find that it
> > does *not* return the full path of the group, instead it just returns the
> > name of the leaf node. So either the routine or the documentation is
> > wrong on that, but I'm not sure which it is.
> >
> > Lastly, and this is obviously related to the above, in the documentation
> > for nc_inq_grpname, the fully qualified group name is not indicated as
> > starting with a forward slash, although the root group's name appears to
> > be "/". I'm hoping that, to be consistent, a fully qualified group name
> > will have the form of "/group1/subgroup1" and not "group1/subgroup1".
> >
The slash is there, it was just documented wrong. Thanks for pointing this
out!
Ed
Ticket Details
===================
Ticket ID: YHC-662367
Department: Support netCDF
Priority: High
Status: Closed