Re: Quincey - Question about character

NOTE: The 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 
[128.117.140.88])
        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[1][1]
            coord[0][0] = 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[1];
            hssize_t *pcoord = coorda;
            coorda[0] = 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


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