Closed willow-ahrens closed 1 year ago
Ah, right, the types ought be explicit in the spec.
The integer type names are from stdint.h
C header file:
int8: int8_t
int16: int16_t
int32: int32_t
int64: int64_t
uint8: uint8_t
uint16: uint16_t
uint32: uint32_t
uint64: uint64_t
And floating point types are:
float32: float or float32_t (IEEE 754 binary32)
float64: double or float64_t (IEEE 754 binary64)
I don't know if we have other types such as bool
, complex64
, int128
, float16
, strings (constant or variable size), datetimes, timedeltas, and user-defined types pinned down yet. I believe we want to defer to the underlying storage to handle endianness.
Some possibly useful links:
@jim22k and @BenBrock have been closer to implementations and can probably say where we are with e.g. bool
.
I see! All of these names are sortof up to the implementer to represent faithfully in the host language, so I think that uint8_t
would be a fine choice for the hdf5 array type, and "bool" would be a fine string to hint for the user to decide how bools get represented in their language.
I'll update my parser, and I'd be happy to add a PR for the spec for this if you'd like.
When the descriptor says "uint64", I think I know how to make the appropriate type, but how can I resolve these type names more formally? Are they names of C datatypes?