From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13320 invoked by alias); 8 Jan 2008 21:27:41 -0000 Received: (qmail 13311 invoked by uid 22791); 8 Jan 2008 21:27:40 -0000 X-Spam-Check-By: sourceware.org Received: from ns2.uludag.org.tr (HELO uludag.org.tr) (193.140.100.220) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Jan 2008 21:27:20 +0000 Received: from ninjamobile.local (unknown [85.97.18.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by uludag.org.tr (Postfix) with ESMTP id 5FD4C61F265C for ; Tue, 8 Jan 2008 23:27:06 +0200 (EET) From: Ismail =?utf-8?q?D=C3=B6nmez?= To: gcc@gcc.gnu.org Subject: Changes in C++ FE regarding pedwarns to be errors are harmful Date: Tue, 08 Jan 2008 21:27:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20071204.744707) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801082328.22849.ismail@pardus.org.tr> X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00065.txt.bz2 Hi all, Looks like gcc 4.3 has some rather inconvenient changes in C++ FE, with the latest trunk. Lets see with an example : [~]> cat test.cpp #define foo bar #define foo baz [~]> g++ -c test.cpp test.cpp:2:1: error: "foo" redefined test.cpp:1:1: error: this is the location of the previous definition I don't know the reasoning behind this change but this breaks many C++ programs unless -fpermissive is used. Why? Because everybody loves to install their own config.h (Python, libmp4v2 being nice examples) which just carelessly #define anything its asked for with ifndef ... endif . Now flash back to real world: this breaks any C++ application that uses Python, libmp4v2, libjpeg and possibly many others. And I think this is a real bad behaviour change and I am not sure if its worth all the trouble. So I am asking, would C++ FE maintainers would agree to revert this into a warning as in C FE now. I welcome and value your comments, so please speak up. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.