From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7066 invoked by alias); 15 May 2007 07:46:53 -0000 Received: (qmail 7049 invoked by uid 22791); 15 May 2007 07:46:52 -0000 X-Spam-Check-By: sourceware.org Received: from tneu02.synserver.de (HELO tneu02.synserver.de) (217.119.58.222) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 15 May 2007 07:46:49 +0000 Received: from [192.168.0.2] (dslb-084-058-217-187.pools.arcor-ip.net [84.58.217.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tneu02.synserver.de (Postfix) with ESMTP id 3CE2C683EA; Tue, 15 May 2007 09:46:45 +0200 (CEST) Message-ID: <46496564.1070603@users.sourceforge.net> Date: Tue, 15 May 2007 07:46:00 -0000 From: Thomas Neumann User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Andrew Pinski CC: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] compiling gcc with a C++ compiler 4/n References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg00943.txt.bz2 Hi, > I don't see why you are doing: > -typedef struct eh_region *eh_region; > > +typedef struct eh_region_def * eh_region; the old typedef created one eh_region type (a struct) in the struct namespace, and a different eh_region type (a pointer to a struct) in the global namespace. This is unfortunately not valid C++. So I had to rename either the struct or the pointer to the struct. I renamed the struct, as I thought the pointer would be the proper outside representation (i.e. users of the exception handling logic do not care about the struct). By looking at the code I think this is right (forward declaration only plus typedef in header), only that most code did not use the typedef to begin with... But of course I can rename the typedef and keep the struct if you prefer. > In fact, you the code worse to read as you used: > #ifdef __GENGTYPE__ this is true, and indeed an ugly piece of code. Strictly speaking a limitation of gengtype (as the proper typedef is in the header), but I am open to suggestions to eliminate it. Unfortunately this does not seem to be simple: > why not change the typedef to be en_region_ptr instead? It gets > around the need for this hackery and the amount of changes you are > doing. Renaming the typedef does not solve the problem, I think. Of course you will know better, but I thought the issue is that the typedef is on a forward-declaration of a struct, which is then defined later. Perhaps I misunderstood the gengtype output, though, I can try to the other way if you think it works. > Also by the way you need to list all the functions you are > changing. And say more of what you are doing in your changelog > entries because right now they are lacking and not to what the coding > style says they should be. sorry for this, I only submit patches since a few days... Could you be a bit more specific about what I should write? I interpreted the FSF instructions such that: - if a changes is all over the place (renaming a member e.g.) you just write "func:c: What did I change" - if it is indeed limited to a function you write "func.c (func): What did I change in the func". Or do you mean that "Cast as needed" etc. is too generic? I will write as detailed descriptions as you like, but I thought that explaining the reasons for obvious casts was not really helpful. Thomas