NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

Re: Creation order: time stamps or sequence numbers

NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.

Hi Russ,

> >     I think supporting creation order for attributes might be a bit
> > more of a problem than for the other kinds of objects, but from
> > reading your description of the attribute number below, it doesn't
> > look like it's a real problem if the "creation order" of attributes
> > changes.  Is that so?
> 
> Oops, I realize I didn't actually answer the question.  The netCDF
> interface (for mostly historical reasons that are hard to justify now)
> permits deleting attributes but not deleting variables or dimensions.
> So attribute numbers can change if you delete preceding attributes,
> but that doesn't change the order of remaining attributes.  The only
> way to change the attribute order would be to delete an attribute and
> then later re-add it at the end, but doing that would have to be
> intentional, so the new order is still preserved.
    Ok, I reviewed our code for attributes and we are already handling them
in a manner which preserves the creation order, so that shouldn't be a
problem.  (I did add a note to write a unit test that verifies that this
continues to be so, also :-)

    Quincey
>From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 17 2003 Nov -0700 07:19:56 
Message-ID: <wrxy8ufjcvn.fsf@xxxxxxxxxxxxxxxxxxxxxxx>
Date: 17 Nov 2003 07:19:56 -0700
From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx>
To: netcdf-hdf@xxxxxxxxxxxxxxxx
Subject: Quincey - Question about character
Received: (from majordo@localhost)
        by unidata.ucar.edu (UCAR/Unidata) id hAHEJwvq003284
        for netcdf-hdf-out; Mon, 17 Nov 2003 07:19:58 -0700 (MST)
Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu 
[128.117.140.88])
        by unidata.ucar.edu (UCAR/Unidata) with ESMTP id hAHEJvOb003280
        for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Mon, 17 Nov 2003 07:19:57 -0700 (MST)
Organization: UCAR/Unidata
Keywords: 200311171419.hAHEJvOb003280
Lines: 13
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx
Precedence: bulk

Howdy Quincey!

Is it the intention that the HDF5 type H5T_NATIVE_CHAR for ASCII
strings, H5T_NATIVE_UCHAR for unsigned byte data, and H5T_NATIVE_SCHAR
for signed byte data?

I'm suprised and very happy if so, because it would be very handy for
me to have a type for ASCII data which is different from signed char
data.

Thanks,

Ed


  • 2003 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-hdf archives: