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 [18.104.22.168]) 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