Version numbers

[Freddie Akeroyd]

It would be nice to allow all data types, but problems occur with
FORTRAN. In C whether a char* refers to a UINT8 or a CHAR8 is not
distinguised, but in FORTRAN it is. In C you can write your strings as
UINT8 and all is fine so long as you read them back as a UINT8; however
as FORTRAN strings are stored differently to streams of bytes i need to
do a conversion in the interface and hence i need to know whether
something is a string or not. There is also a "null" termination
problem with the current C implementation if it were used for 8 bit
data. Currently if you wrote 8 items of 8 bit data, you would need to
send an array of length 9 to read them back in again or else your last
element would be chopped by the '\0'. Allocating 1+length is natural
for C programmers using strings, but not for C (or FORTRAN) programmers
handling arrays of 8 bit data! While you might notice your string being
one character shorter and fix it, you may not notice your final data
point being replaced by 0. One way round this would be the "strncpy"
solution i mentioned to a previous attributes query where the interface
only null terminates a string it is passed more space than is required
to store it. Basically we have a backward compatability problem as strings
were previously written as UINT8. In C we can do a partial workaround,
but the FORTRAN interface has to go one way or the other - if we stick
to a rigid NX_CHAR only, then it will not be able to read old PSI
data. I guess the question is what counts more - being able to write 8
bit data values or being able to read old PSI data from the FORTRAN
interface?

Freddie
> 
> Regarding the CHAR8, UINT8, INT8 stuff, characters should be characters,
> integers should be integers, and uints should be uints.  The advantage
> comes at readout time.  If you are trying to make a displayer, then how you
> disply the SDS or attribute depends upon which type it is.  We should allow
> SDS's to be characters, otherwise we have to support other HDF
> constructions for storing string information.  I do not see any real need
> to have an 8 bit int (or unit) attribute, however, why impose that
> limitation?  Just let people store what the need/want.  As soon as you
> exclude it, you will find that somebody needs it, and some other software
> will not work with the change.
> 
> Jon
> 
> >What is the final word on NX_CHAR? Currently the NAPI code writes
> >NX_CHAR as DFNT_CHAR8, but treats attributes read in as DFNT_UINT8,
> >DFNT_CHAR8 or DFNT_UCHAR8 as character types (for backward
> >compatability) and NULL terminates them; however it looks like the
> >current NXdict API uses DFNT_INT8 as the character type.  This may not
> >be a problem if we don't allow 8 bit values to be anything other than
> >strings when they are in attributes - proper 8 bit numbers should be
> >part of an SDS and not an attribute? Of course, do we then allow SDS's
> >of characters?
> >
> >Freddie
> >
> >P.S. I assume we should write a global attribute "NeXus_version"
> >containing the
> >     API version when we create a new file - i don't believe we do at the
> >moment
> >
> 

-- 
Freddie Akeroyd                        Email:  Freddie.Akeroyd at rl.ac.uk
ISIS Facility                          Tel:    +44 1235 445457
Rutherford Appleton Laboratory         Fax:    +44 1235 445720
Chilton, DIDCOT, OX11 OQX, GB          WWW:    http://www.isis.rl.ac.uk/