Babl half->double conversion does not take endianness into account
Submitted by Massimo
Link to original bug (#760703)
Description
On my platform running
valgrind gegl -o tmp.png tests/compositions/tiff-load.xml
shows many occurrences of:
==21258== Conditional jump or move depends on uninitialised value(s) ==21258== Use of uninitialised value of size 8
This is because that test loads a 16bit float tiff that is then translated and so converted to "RaGaBaA float" and the conversion goes throw the reference path that invokes a half->double conversion.
As seen here:
https://git.gnome.org/browse/babl/tree/babl/base/type-half.c#n283
probably for performance reasons, the remaining 32 bits are skipped.
I don't know how much it is gained writing every other 32bit word as I consider writing to memory a kind of write to a block device where at least sequential and contiguous writes are often combined, but I never measured it.
What are the pratical consequences of this choice?
I'd say that it is possible that zero halfs are converted to non zero doubles (denormal?) and an empty GIMP selection could appear non empty, in fact valgrind reports similar warnings creating a new 16 bit float image
It is possible that a reference path conversion randomly differs from an exact fast path hardware assisted conversion, if the difference can be greater than BABL_TOLERANCE the fast path would be rejected.
valgrind output contains warnings.
Version: git master