netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi Ed, The H5T_NATIVE_<foo> types are designed to provide an explicit mapping between C types and datatypes in HDF5, for example: H5T_NATIVE_CHAR -> 'char' H5T_NATIVE_UCHAR -> 'unsigned char' H5T_NATIVE_SCHAR -> 'signed char' H5T_NATIVE_INT -> 'int' (or 'signed int') H5T_NATIVE_UINT -> 'unsigned int' Because the signedness of 'char' in C is compiler implementation specific, the HDF5 library chooses whether it is a 'signed char' or a 'unsigned char' at the time the library is compiled. This doesn't really answer your question about "how to store ASCII" data in the file, because that really depends on how the user application is trying to store the ASCII data in the file. If they are just using 'char' types in C, then it may be fine to map that to H5T_NATIVE_CHAR, but I would normally suggest storing ASCII data as an HDF5 string datatype. HDF5 string datatypes (with H5T_C_S1) have more control about the string padding (nulls or spaces) and the string's character set (although we only support H5T_CSET_ASCII at the moment, it will be possible to support unicode in the future). Does that help? 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 > >From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 20 2003 Nov -0700 09:35:32 Message-ID: <wrxd6bnc817.fsf@xxxxxxxxxxxxxxxxxxxxxxx> Date: 20 Nov 2003 09:35:32 -0700 From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx> To: netcdf-hdf@xxxxxxxxxxxxxxxx Subject: a C programming question for you all: using H5Sselect_elements without a cast? Received: (from majordo@localhost) by unidata.ucar.edu (UCAR/Unidata) id hAKGZfdE007425 for netcdf-hdf-out; Thu, 20 Nov 2003 09:35:41 -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 hAKGZbEH007340 for <netcdf-hdf@unidata>; Thu, 20 Nov 2003 09:35:37 -0700 (MST) Organization: UCAR/Unidata Keywords: 200311201635.hAKGZbEH007340 Lines: 41 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 Hello all! Here's a C programming question. There is a function: herr_t H5Sselect_elements(hid_t space_id, H5S_seloper_t op, const size_t num_elements, const hssize_t *coord[ ] ) If I try this, for accessing one element of a one-dimensional array: hssize_t coord coord = attnum; if (H5Sselect_elements(att_info_spaceid, H5S_SELECT_SET, 1, coord) < 0) The compiler whines at me: nc4hdf.c:446: warning: passing arg 4 of `H5Sselect_elements' from incompatible pointer type So how the heck can I call this thing without a warning? I also tried: hssize_t coorda; hssize_t *pcoord = coorda; coorda = attnum; if (H5Sselect_elements(att_info_spaceid, H5S_SELECT_SET, 1, pcoord) < 0) BAIL(NC_EHDFERR); but I got the same warning, which didn't suprise me, as this is the same thing expressed sightly differently in C. Of course I could take the easy way out, which the HDF5 sample code does, of casting it: ret = H5Sselect_elements(fid, H5S_SELECT_SET, NPOINTS, (const hssize_t **)coord); But isn't there any better way? Ed