some words about dds.cpp:

line 500:       b = (uint &) bits[3];

looks a bit dangerous as bits is defined as uchar bits[6];
For sizeof(uint) == 32, this will read 8 bits beyond the end of the array. I do not know if uint has a fixed width here. But if not, things may be even worse.


line 498: bit_array[7] = uchar(b & 0x07); b >>= 3;
line 508: bit_array[15] = uchar(b & 0x07); b >>= 3;

b >>= 3 can be dropped as the results are discarded

It is worse. The code does not respect endianness of the CPU.

    b = (uint &) bits[3];

should probably be converted to

    b = bits[3] | (bits[4] << 8) | (bits[5] << 16);

Unfortunately, I have no test files to find regressions, so I don't really want to touch it.

Here's the report from kdelibs-4.6.95 (4.7-rc2).  Very similar, except the first one, kmimetypefactory, is now kmimetyperepository:

 * QA Notice: Package has poor programming practices which may compile
 *            fine but exhibit random runtime failures.
 * /tmp/portage/kde-base/kdelibs-4.6.95/work/kdelibs-4.6.95/kdecore/services/kmimetyperepository.cpp:444:127: warning: dereferencing type-punned pointer will break strict-aliasing rules
 * /tmp/portage/kde-base/kdelibs-4.6.95/work/kdelibs-4.6.95/kimgio/dds.cpp:490:33: warning: dereferencing type-punned pointer will break strict-aliasing rules
 * /tmp/portage/kde-base/kdelibs-4.6.95/work/kdelibs-4.6.95/kimgio/dds.cpp:500:28: warning: dereferencing type-punned pointer will break strict-aliasing rules
 * /tmp/portage/kde-base/kdelibs-4.6.95/work/kdelibs-4.6.95/kdeui/util/kcrash.cpp:609:26: warning: dereferencing type-punned pointer will break strict-aliasing rules

*** Bug 311225 has been marked as a duplicate of this bug. ***

Created attachment 79865 [details]
Fix type-punning QA problems in kdelibs (patch against current master)

I noticed this bug on a kdelibs-bugs mail from one of the duplicates, was surprised no one had been able to close it so decided to fix myself.

Christoph, would you mind reviewing for sanity before I go and commit (only to master at this point)?

I've tested as best I can (even to the point of starting a process from klauncher and force-crashing it to make sure kcrash can still read the PID).

I've even tested the DDS reader (though that code has other issues of its own), the Civ IV game has DDS format files which all appear to still read correctly (I had to use Okteta to make sure the DDS files had the right FourCC format to hit the affected code).

Thanks Michael for testing the DDS reader and KCrash.

As for the MIME stuff, David might want to have a look at it, he also knows if it's better to commit to 4.10 branch or master.

dfaure, would you mind reviewing my proposed type-punning fix for kmimetyperepository (the first attachment to this bug) to see if it is suitable for inclusion to master and/or KDE/4.10 of kdelibs?

Git commit 01c098da6a43a23bacfd7ffe60393b06dd401deb by Michael Pyne.
Committed on 18/05/2013 at 23:08.
Pushed by mpyne into branch 'master'.

Fix type-punning/non-standard-aliasing issues.

Reported aeons ago as bug 259826, somehow evaded interest up to this
point.

The issue is essentially that the C++ standard allows compilers to
optimize some forms of crazy type changes, which makes the flagged code
dangerous in the face of "future optimization improvements".

None of the flagged code was so crazy that it couldn't have been
implemented in a more straightforward fashion though. The only change
I'm not 100%-alright with is the change to dds.cpp, but that code has
other issues anyways (though I did test that it still works as much as I
could).

However because of the risk of breakage I do not intend to backport.
Hopefully sufficiently-smart compilers will wait until the next major
release.
FIXED-IN:4.11

M  +4    -3    kdecore/services/kmimetyperepository.cpp
M  +1    -2    kdeui/util/kcrash.cpp
M  +5    -4    kimgio/dds.cpp

http://commits.kde.org/kdelibs/01c098da6a43a23bacfd7ffe60393b06dd401deb