[Nexus] nullpad vs. nullterm strings

Tobias.Richter at diamond.ac.uk Tobias.Richter at diamond.ac.uk
Wed Mar 20 17:47:21 GMT 2013

Hi Paul,

That seems very sensible. I've hit that problem before as well but didn't investigate further.
Please put that in.



From: nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org] on behalf of Paul Kienzle [paul.kienzle at nist.gov]
Sent: 20 March 2013 16:28
To: nexus at nexusformat.org
Subject: [Nexus] nullpad vs. nullterm strings


I'm trying to use h5py to create NeXus files at the NCNR, but I'm running into the problem that h5py creates strings using


but napi expects strings created using


The effect is that the strings I create in h5py have the final character chopped off when I view them using napi.

I spent some time trying to get h5py to produce NULLTERM strings from the high level interface, but no luck so far.

There are a couple of workarounds, like making string fields one character longer or making them variable width, but that's just wrong.

Easiest would be to fix napi5.c so that it respects the stored string format.  Right now the code looks like:

     else if (tclass==H5T_STRING)
        len = H5Tget_size(pFile->iCurrentT);
        memtype_id = H5Tcopy(H5T_C_S1);
        H5Tset_size(memtype_id, len);
        status = H5Dread (pFile->iCurrentD, memtype_id,
                       H5S_ALL, H5S_ALL,H5P_DEFAULT, data);
       memtype_id = h5MemType(pFile->iCurrentT);
       status = H5Dread (pFile->iCurrentD, memtype_id,
                       H5S_ALL, H5S_ALL,H5P_DEFAULT, data);

NX5getattr doesn't have this problem because it uses H5Aget_type. Since pFile->iCurrentT already contains H5Dget_type, we can just use it directly.  This simplifies the code to:

     else if (tclass==H5T_STRING)
        status = H5Dread (pFile->iCurrentD, pFile->iCurrentT,
                       H5S_ALL, H5S_ALL,H5P_DEFAULT, data);

A similar change is needed for getslab, though it's looks like napi doesn't support getslab on n-d string arrays, so it doesn't matter.

Any objections to pushing this change?

  - Paul

NeXus mailing list
NeXus at nexusformat.org

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

More information about the NeXus mailing list