Improve code quality by enabling more compiler warnings

[diederik]

The quality of the code could be improved by enabling more compiler warnings, and fixing that code.

The most useful one (which currently is not enabled) is:

• -Wold-style-cast - a warning is issued whenever a C-style (type) cast is performed instead of C++-style x_cast<type>() casts.

And less relevant for now:

• -Wfatal-errors
• -pedantic

[valerio]

I think "boom" :P

[diederik]

Enabled all except for:

• -pedantic
• -Wfatal-errors

[valerio]

The only warning I got is about the use of preprocessor "#warning"s.

[diederik]

The warnings don't seam to add much value. Instead I've sent a request to Coverity to be included in their free Open Source scans. We could also install the KDE source code checker ('Krazy') too :)

[valerio]

The only useful warning is 'old-style-cast' which generates thousands of warnings in our SVN code.

The others are pretty useless indeed; I suggest enabling old-style-cast alongside a major code reformatting - maybe with the help of some automatic code reformatter.

[valerio]

I've fixed a lot of them. We still have those related to P2PMessage::insertBytes().

If you look at src/network/applications/p2papplicationbase.cpp, from line 1699 on, you'll see that there's two apparently unused fields, set to zero: but isn't it probable that the relevant fields are just double the size they're now? I suggest an overload of insertBytes() which accepts an unsigned long for those.

For the rest of those insertBytes() warnings, I guess that there's no support in MSNP2P at all for those, so using bigger integers ourselves isn't useful.. can I switch everything to use quint32 or maybe I should just cast them when they're used on insertBytes() and keep them as longs?

[diederik]

Yes, some fields are 8 bytes long. The exact fields are documented in the APIDOX header of p2papplicationbase.h.

I never bothered to handle this because it would mean you're sending files larger then *yuck* 4GB over MSN.

The size of an unsigned long can still be an 32 bit integer, so it would need to be a quint64 - if that even exists - combined some smart data type handling (since you're at a 32-bit platform).

Using quint32 would be ok for me.

[valerio]

Patch to fix the last compiler warnings. Tested locally with 7mb file and md5sum.

[valerio]

The patch to fix the warnings is in SVN, r3988.

I'll close this one, enabling more compiler warnings wouldn't help much with code quality improvement anymore..