From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17059 invoked by alias); 27 Sep 2002 21:08:56 -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 17050 invoked from network); 27 Sep 2002 21:08:55 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 27 Sep 2002 21:08:55 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g8RL6nl01704; Fri, 27 Sep 2002 14:06:50 -0700 Date: Fri, 27 Sep 2002 15:18:00 -0000 From: Mark Mitchell To: Richard Henderson cc: Gabriel Dos Reis , "gcc@gcc.gnu.org" Subject: Re: C ABI: struct/union inconsistency Message-ID: <95350000.1033160809@warlock.codesourcery.com> In-Reply-To: <20020927204348.GC19608@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-09/txt/msg01133.txt.bz2 --On Friday, September 27, 2002 01:43:48 PM -0700 Richard Henderson wrote: > On Fri, Sep 27, 2002 at 11:52:46AM -0700, Mark Mitchell wrote: >> My point was that I would like a header file that looks like: >> >> extern "C" { >> struct S {}; >> ... >> } >> >> to have the same meaning in both languages; that's not possible if S has >> size zero in C. > > It's also not possible if one writes > > extern "C" { > struct S { > const int i; > }; > } > > as they have different meanings in C and C++. So I don't see that your > point necessarily holds. The fact of the matter is that the two languages > do not line up 100%, and one has to live with it. That's true -- there are a few other places in the common subset that don't line up in terms of semantics. As far as I know, however, this empty struct issue is the only one that has an effect on layout, which is clearly a very important issue. Most of the other issues result in errors in one language or the other. If emtpy structures were rejected in C mode, I'd be much less nervous; at least the errors would be easily detected. Why not ask the kernel developers about something like: struct S __attribute__((possibly_empty)) {}; ? The idea being that if S has no members, the size ends up zero. We could support this attribute in C++ as well, and then have compatibility between C and C++. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com