On Mon, Jun 25, 2007 at 12:33:20PM +0200, Matthias Klose wrote:
> Michael Hanke writes:
> > nifti1.h:#define DT_FLOAT128 1536 /* long double (128 bits)
> > */
> > nifti1.h-#define DT_COMPLEX128 1792 /* double pair (128 bits)
> > */
> > nifti1.h:#define DT_COMPLEX256 2048 /* long double pair (256
> > bits) */
> > nifti1.h-/* @} */
> > nifti1.h-
> > nifti1.h-
> > nifti1.h- /*------- aliases for all the above
> > codes ---*/
> > --
> > nifti1.h- /*! signed long long. */
> > nifti1.h-#define NIFTI_TYPE_INT64 1024
> > nifti1.h- /*! unsigned long long. */
> > nifti1.h-#define NIFTI_TYPE_UINT64 1280
> > nifti1.h: /*! 128 bit float = long
> > double. */
> > nifti1.h-#define NIFTI_TYPE_FLOAT128 1536
> > nifti1.h- /*! 128 bit complex = 2 64
> > bit floats. */
> > nifti1.h-#define NIFTI_TYPE_COMPLEX128 1792
> > nifti1.h- /*! 256 bit complex = 2 128
> > bit floats */
> > --
> > nifti1.h- /*-------- sample typedefs for complicated
> > types ---*/
> > nifti1.h-#if 0
> > nifti1.h-typedef struct { float r,i; } complex_float ;
> > nifti1.h-typedef struct { double r,i; } complex_double ;
> > nifti1.h:typedef struct { long double r,i; } complex_longdouble ;
> > nifti1.h-typedef struct { unsigned char r,g,b; } rgb_byte ;
> > nifti1.h-#endif
> > nifti1.h-
> > nifti1.h-/*---------------------------------------------------------------------------*/
> >
> > So the matching datatype definition is just an example. The other
> > datatypes already assume a 128bit representation, but are simply labels
> > that have to be supplied be the user to identify the datatype of binary
> > chunks stored inside to-be-read files.
> >
> > I think it is save to close this bug.
>
> not all of it is commented out. are the macros used somewhere in the
> code? are the used in code in packages which b-d on this package?
The macros are used to the report string labels of the datatypes for UIs
and to distinguish between float and interger datatypes. Most
importantly they define how many bytes an element of this datatype has.In case of *FLOAT128 this is set to 16 bytes (no arch differences). So if I understand it correctly this library was broken on the arches now doing the transition, right? If this is correct renaming the package is not necessary even if there is code that uses this lib, all dependencies were broken and the transition fixes this bug. Possible packages affected by this bug could be: python-nifti* dicomnifti* xmedcon medcon libmdc2 * maintained by me Please note, that this datatype is very, very uncommon in the area this library is used. Although the library version currently being in etch has this bug I think fixing it isn't worth the effort. However, do you know of more inconsistencies between the datatype sizes of different arches supported by Debian. This library currently make no differences wrt arches and datatypes. Perhaps there are even more bugs. So you agree? Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050
signature.asc
Description: Digital signature
