
Clang now builds Postgres without additional warnings - stesch
http://pgeoghegan.blogspot.com/2011/08/clang-now-builds-postgres-without.html
======
palish
I write all my C and C++ code at warning level 4 (the maximum, which is
probably equivalent to -Wall). IMO, it was a mistake for Visual Studio to
default to warning level 3. Ignoring the compiler in production code is a sign
of laziness, or that you don't take what you're doing seriously.

Warnings should be disabled on a per-source-file basis. And since you
_actively choose to ignore_ specific warnings, you still benefit from the
compiler's other sanity checks.

In Visual Studio, this is accomplished by

    
    
      #pragma warning( disable: 4100 )
    

at the top of a .c or .cpp file. This will ignore "unreferenced parameter"
warnings. (Personally, I don't ignore those either. It's saved me on more than
one occasion, and once is enough for me. So instead, I use a macro
UNREF_PARAM(param) to suppress the warning in specific cases.)

A header file sometimes generates a warning that you want to choose to ignore.
But if we disabled it in the header file, then that disable would propagate to
all other code which included the header file -- a big mistake!

Visual Studio solves this by:

    
    
      #pragma warning( push )
      #pragma warning( disable: 4100 )
      //----------------------------------------------------
      // foo.h
      //   The Foo module serves as an example of how to
      // properly suppress the "unreferenced parameter"
      // warning within a header file, via Visual Studio's
      // #pragma warning( push ) and pop mechanism.
      //----------------------------------------------------
      /*
        .... code which generates the warning ....
      */
      #pragma warning( pop )
    

This allows you to "scope" the disable to a single header file.

(Lastly, it's worth noting that SQLite outputs hundreds of warnings --- but
they are neither lazy nor irresponsible, because they have hundreds of unit
tests to verify that SQLite works correctly at runtime, as defined by the
tests, across all platforms.)

~~~
burgerbrain
Surely there is such a thing as a piece of code that generates very legitimate
warnings, but happens to compile to something that appears to work under at
least most circumstances.

Ignoring compiler warnings _does_ seem pretty irresponsible to me, no matter
how superb your unit test coverage is. At the very least it will cause a
degregation of the codebase over time.

~~~
pestaa
And how exactly could SQLite benefit from warning-free compilation? It not
only appears to work but it does its job pretty well.

Unit tests prove a different level of semantics that these warnings cannot
substitute (although possibly complement).

~~~
palish
Tests and warnings compliment each other nicely.

"My, you're looking testy today!" ...

burgerbrain points out something very important: Code bases with warnings tend
to be degenerate.

 _Tend_ to. SQLite is not one of them. But I've seen several large codebases.
The two which were beautiful also had zero warnings, and the ~dozen others
ranged from "meh" all the way down to "lol, grab a snickers".

This is obviously not enough data to draw any meaningful statistical
conclusions from --- but it would be silly to ignore it completely. Good C/C++
programmers tend to respect compiler warnings.

------
jarjoura
I've switched my FreeBSD machine over to clang and have been successfully
building most ports with it. It really is ready for prime-time :-).

~~~
schrototo
If I remember correctly from this and last years WWDC, large parts (if not all
by now) of iOS and OS X Lion are built with Clang/LLVM and have been for some
time. I'd say Clang's been ready for a while!

------
scorpioxy
Great. But what does that mean to Postgres users?

Does it affect the performance? Would it be easier to uncover more bugs moving
on?

~~~
wulczer
Right now it's more useful for uncovering bugs, I don't think anyone would
recommend running Postgres compiled with clang on a production system.

For more info about performance, see
[http://pgeoghegan.blogspot.com/2011/07/could-clang-
displace-...](http://pgeoghegan.blogspot.com/2011/07/could-clang-displace-gcc-
generally-part.html)

