[Nexus-developers] API state

[Akeroyd, FA (Freddie)]

The XML interface uses the XML attribute "type" to store the data type
of an item - this is treated as a real attribute by
NXgetattrinfo/NXgetnextattr so if you convert a file from HDF -> XML you
appear to gain an attribute. As the "type" attribute is special I think
it should be hidden from the user who calls NXgetattrinfo/NXgetnextattr
and also if the user tried to set "type" via NXputattr they should get
an error. In fact, protecting "type" is important because a user could
legitimately set an attribute called "type" in HDF which would cause
problems when the file was converted to XML. I guess a similar argument
applies to the "target" attribute too - we should really prefix all
NeXus special internal attributes with something ("nx","_", ...) and
then disallow setting of attributes with this prefix from the usual
interface.  

I've made the search for "libsz.a" better in configure; does that help?

Freddie

> -----Original Message-----
> From: nexus-developers-bounces at anl.gov [mailto:nexus-developers-
> bounces at anl.gov] On Behalf Of Mark Koennecke
> Sent: 20 May 2005 10:19
> To: nexus-developers at anl.gov
> Subject: [Nexus-developers] API state
> 
> High everyone,
> 
> I fixed the issue with the XML-API by now. It actually was much more
> serious, the XML-API was
> reading wrong numbers. Nobody noticed.... This was a bug in mxml which
I
> resolved. Thus, the only
> version of mxml which works is 2.2.2 as released yesterday!
> 
> There is another issue with the test not working under SL 3.0.4 and
Suse
> Linux 9.2. Now, I spent a lot
> of time with this. The first result was that the test programs would
> fail within libc if hdf5 was involved.
> I tried various ways to improve on this by trying to initialize the
hdf5
> library before use. The hdf5 library is
> used even if hdf4 or xml files are read in order to test if a given
file
> is hdf5. The hdf team told me that there
> is no other  means of testing  for hdf5, no magic number. I obtained
the
> best result when I put a
> H5open into the top of the test program napi_test.c. My next guess was
> to run strace upon the problem. For
> non unix guys: strace traces in much detail all system calls. This
> showed me that the segfault  was right after  a
> call to munmap. Apparantly Linux memory maps files for reading. I also
> ran the program through valgrind, a
> very thorough memory debugging program. This yielded no errors in our
> code or the hdf*, xml libraries.
> I am now coming to the conclusion that the problem is in libc or gcc,
> both of which I do not wish to debug.
> If someone experiences the problem she should update both gcc and libc
> to newer (or older?) versions.
> 
> There is still a small issue with the build process if you build a
> version including a recent version of hdf4 but
> no hdf5. Then the -lsz is missing on the link. This can be overcome by
> setting
> LDFLAGS to "-Lpath-to-you-szlib -lsz" before running configure.
> 
>  What do you think?
> 
>                                          Mark
> 
> 
> 
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at anl.gov
> http://www.neutron.anl.gov/mailman/listinfo/nexus-developers