Uninitialised memory causing decode failure



we recently stumbled upon an image which failed decoding with a message saying "Codec does not support the image's color transformation" (This is charLS' error UnsupportedColorTransform). Some printf-debugging figured out that the colorTransform was set to 0xCCCCCCCC. Some more debugging figured out that this was due to uninitialized memory.

The attached patch makes JpegMarkerReader zero out its JlsParameters instance before using it. As far as I can tell, this is the only place were a JlsParameters instance is constructed without getting assigned values from elsewhere. At first, I wanted to add a suitable default constructor to JlsParameters, but since this is in interface.h, this isn't possibly.

Feel free to come up with a less ugly patch for this issue (and perhaps even a comment explaining why this is necessary?).


file attachments

Closed Jan 2, 2015 at 10:32 AM by vbaderks
Patch not applicable for master branch. CharLS 2.0 requires C++ 11 compiler.


awik wrote Oct 12, 2012 at 9:28 AM

It seems that in CharLS 1.0 this patch should be applied inJLSInputStream::JLSInputStream(const BYTE* pdata, size_t cbyteLength)constructor body.

jdv wrote Oct 25, 2012 at 9:09 PM


Sorry for being unresponsive. With what compiler are you seeing this? Either it is not conformant, or I am overlooking something.

the initializer list item " _info() " should default-initialize the variable _info. As this is a struct with no user defined constructor, it should apply the generated default constructor. This calls the default constructor for all members, which are all primitive types, and default-initializing them will boil down to zero-initialize.

psychon wrote Oct 26, 2012 at 2:31 PM

This was seen with MSC6, so the compiler surely is not conformant.

According to 0, the default-initialisation rule was added in C++03, thus 5 years after MSC6 was released. So MSC6 can't really conform to that rule. :-)