From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4527 invoked by alias); 24 May 2005 04:59:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4486 invoked by uid 22791); 24 May 2005 04:59:33 -0000 Received: from smtp-102-tuesday.noc.nerim.net (HELO mallaury.noc.nerim.net) (62.4.17.102) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 24 May 2005 04:59:33 +0000 Received: from uniton.integrable-solutions.net (gdr.net1.nerim.net [62.212.99.186]) by mallaury.noc.nerim.net (Postfix) with ESMTP id E095C62D22; Tue, 24 May 2005 06:59:26 +0200 (CEST) Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O6A9Lv017506; Tue, 24 May 2005 08:10:10 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id j4O6A9Gs017505; Tue, 24 May 2005 08:10:09 +0200 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Daniel Jacobowitz Cc: Zack Weinberg , gcc@gcc.gnu.org, jason@redhat.com, mark@codesourcery.com, dberlin@dberlin.org Subject: Re: Compiling GCC with g++: a report References: <1116907280.9577.31.camel@localhost.localdomain> <20050524035919.GA23335@nevyn.them.org> From: Gabriel Dos Reis In-Reply-To: <20050524035919.GA23335@nevyn.them.org> Date: Tue, 24 May 2005 06:22:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-05/txt/msg01275.txt.bz2 Daniel Jacobowitz writes: | On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote: | > As a general observation: A lot of the things you have found to be | > problematic, are in fact preferred idioms for C code. For instance, | > no standard-C programmer would ever write an explicit cast on malloc's | > return value. I think that we are losing something, if only in | > readability, if we restrict our code to the subset of C which is also | > correct C++. Now, if we were migrating to C++, that would be okay, | > because we would (eventually) get all of the additional expressive power | > of C++ in exchange. However, if we're not migrating to C++, I'm opposed | > to the inclusion of patches that restrict our C code to the subset which | > is correct C++. Furthermore, as I've said before, I support migrating | > to C++ -- but only if the C++ ABI and libstdc++ soname are first | > permanently frozen. If we do not do that first, we risk being trapped | > into a situation where we need specific versions of GCC to compile | > specific newer versions of GCC, which would be a Bad Thing. | | You keep saying this and I don't think it means what you think it | means... Furthermore, I do not believe doing that (at least, as I understand it is any resonable. At any case, it is completely indpendent of the patches that align us to our coding standards. -- Gaby