Compilation strict mode and warnings cleanup for GCC 4.1

[qgib]

Author Name: Mateusz Loskot - (Mateusz Loskot -)
Original Redmine Issue: 1239

Redmine category:build/install
Assignee: nobody -

---

I've prepared a patch for trunk/qgis subtree that enables more strict compilation with GCC 4.1 and cleans number of warnings.

Here is cmake comamnd I used to test compilation after the cleanup:

cmake \\
 -D CMAKE_INSTALL_PREFIX=$HOME/usr \\
 -D CMAKE_BUILD_TYPE=Debug \\
 -D CMAKE_CXX_FLAGS:STRING="-pedantic -Wall -Wno-long-long -fstrict-aliasing -Wstrict-aliasing=1" \\
 -D CMAKE_VERBOSE_MAKEFILE=TRUE ..

I would suggest to use the CMAKE_CXX_FLAGS above as default compilation flags. It really helps to find subtle bugs. During the cleanup work, with help of the stricter compilation mode I've identified following bugs: #11289, #11293, #11294, #11295, #11296

The only warning that hasn't been cleaned is

warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object

but this is a well known issue of 'dlsym_ call used with C++ compiler (see #10293).

The patch was generated against revision r9120 from inside the trunk using _svn diff' command.

---

• compilation-warnings-and-cleanup-r9120.patch (Mateusz Loskot -)

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

Replying to "mloskot":/issues/show/1239:

I've prepared a patch for trunk/qgis subtree that enables more strict compilation with GCC 4.1 and cleans number of warnings.

Thanks for the patch I applied it in 120a61c (SVN r9134). I didn't change the default compile, but the PEDANTIC mode. PEDANTIC also enables more warnings for the MSVC build. GCC 4.3 and MSVC identified some more problems. And the debian package is now compiled in PEDANTIC mode.

I got a bunch of warnings in Qt headers with strict aliasing (GCC 4.3.1 and Qt 4.4.0). So I didn't enable that.

The only warning that hasn't been cleaned is

> warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object

but this is a well known issue of 'dlsym_ call used with C++ compiler (see #10293).

I made up a cast_to_fptr function with the union approach there. Although that's not a (perfect) solution.

---

• resolution was changed from to fixed
• status_id was changed from Open to Closed

[qgib]

Author Name: Mateusz Loskot - (Mateusz Loskot -)

---

Jef,

Thanks for applying it. A few additional comments.

• You may also add "/Gz":http://msdn.microsoft.com/en-us/library/aa699247(VS.60).aspx and "/Za":http://msdn.microsoft.com/en-us/library/aa278577(VS.60).aspx for Visual C++ compiler.

• cast_to_fptr does not make much sense. It cleans warning but it doesn't solve the problem and dlsym/QLibrary::resolve "still seriously breaks C++ rules":http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.8: It's illegal, period.. Unless, functions being loaded are exported as C functions using extern "C".

I would suggest to enable this warning back, so it's not forgotten. C++ standarization committee has noticed this problem and "is working to find a solution":http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#10254. POSIX gurus have noticed that problem too and probably new version of dlsym will be released in future (see "Rationale":http://www.opengroup.org/onlinepubs/009695399/functions/dlsym.html)

[qgib]

Author Name: Mateusz Loskot - (Mateusz Loskot -)

---

One more note regarding the strict aliasing. Yes, I'd expect Qt breaks strict aliasing rules, however it's a good idea to remember it in case strange and undefined behavior occurs.

Recently, we have experienced such problem in GDAL. It was extremely hard to find out what's going on without enabled strict aliasing warnings. See the story here: "XPlane causes undefined behavior with GCC 4.3.x":http://trac.osgeo.org/gdal/ticket/2521

If I'd be asked to decide, I did keep these warnings enabled, even if they occur in 3rd party libraries. We can't be sure Qt is free of bugs :-)