From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=602N=5Y=gmail.com=jwakely.gcc@sourceware.org>
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630])
	by sourceware.org (Postfix) with ESMTPS id CFC093858C00
	for <gcc-help@gcc.gnu.org>; Fri, 27 Jan 2023 15:32:53 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CFC093858C00
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-ej1-x630.google.com with SMTP id me3so14705251ejb.7
        for <gcc-help@gcc.gnu.org>; Fri, 27 Jan 2023 07:32:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=qJP+2KvUImZX6viwUkTJyV/ZptX1O3+hMjELRao/v80=;
        b=GU6ywo46FLUIX3GV/NCPq60ybbW/YZ7o9f0hhFrkNeT7Cv2kmsi19Pc31VYXnk9A1y
         nrHUeY9NfqW5locKXChmhKfFD3CA+RdiM0a+jFqMfkaL9qBn1VbKnyadEuePjzqaqbvm
         lfFA3ORBIeRY2L7Gsfyr3181Co3rRHW20VckjdfqruZiX4rRWtg15DH7HuTvm0NzKBge
         2ldt5ildeUR9ElAz30RTZQXt8lJF4BUJNFk8cWESiGnKdxrieaU4u9EtVzZdozWGaTNy
         FV7EU6mTd7W36U4HnCnhpWkc0Ke6axBEvODWVip4uvUTwFrsE4CN5HS0w18GYDA0vme1
         m1fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=qJP+2KvUImZX6viwUkTJyV/ZptX1O3+hMjELRao/v80=;
        b=fvMFeu1jeyeFi7AbkfjdsDTHH8WZQus59sitBVfY4InNqfCmVQeNi6l+LR90fruAkj
         5ADcxLkiv4UzoD+Un1SCZnb4Vs650Gc0QDOzxqszaByxZvTDficFIdWsMsEES91MXrtM
         dMgcFZ/uoigfq47CQUJ7t8Ootboq1m1I0UUQbS00CICx8mejzjv5EtrDRK99WHwaBsRV
         8qOcqTLcJIj4zajauHpn95xX2Ayn4hh8lisR/rydxLmH8HtyYsdVuWyn8YH+aGQUqCLO
         yUdgStttRF5XmrzTrevUMjcTC7Q3ek258YGlZuqCvwaz4rF6NaETdTAGFhUYCjQ5c+6/
         cXFQ==
X-Gm-Message-State: AO0yUKWKRALXItjXsMX6A461xrOgVLbTIwbTTLlBrj5x+CFGvTr/V8wS
	hcFnV0+c0y2DbhyuKDYYnZGP7BTw8WBqE2KmCHo=
X-Google-Smtp-Source: AK7set/P9eOjpsYbWCHbBGznUtaLD6eTZX9D9nXP/L0HRzuHw4zhYp4N+EI0LSKoyTRMyHDSf5eXpV+lmG/ydewUE4s=
X-Received: by 2002:a17:906:35d7:b0:87c:aa87:acee with SMTP id
 p23-20020a17090635d700b0087caa87aceemr340964ejb.182.1674833572271; Fri, 27
 Jan 2023 07:32:52 -0800 (PST)
MIME-Version: 1.0
References: <B9798D57-6AD5-42B0-ABD4-28C46BB4D5CB@pe82.de> <CAH6eHdQqJ3-Ac3XQTP6+Rdt3PxXj944hYPwJ-TCZhQTKxKyV=Q@mail.gmail.com>
 <fb4f716dec87539b86deee8f87362c250647ca88.camel@xry111.site>
In-Reply-To: <fb4f716dec87539b86deee8f87362c250647ca88.camel@xry111.site>
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Fri, 27 Jan 2023 15:32:41 +0000
Message-ID: <CAH6eHdRSsz7tkC+od6hobiRjXbSjBC=-48dVreZ6PuGAd2UwAg@mail.gmail.com>
Subject: Re: Correct way to provide a C callback function nside C++
To: Xi Ruoyao <xry111@xry111.site>
Cc: Pepe <list.gcc-help@pe82.de>, gcc-help@gcc.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-help.gcc.gnu.org>

On Fri, 27 Jan 2023 at 14:30, Xi Ruoyao wrote:
>
> On Fri, 2023-01-27 at 14:07 +0000, Jonathan Wakely via Gcc-help wrote:
> > I think it's safe to assume that *either* the code compiles and works
> > as expected, or fails to compile. And in practice it compiles and
> > works with all widely used compilers. You will not find a C++
> > implementation where the types are not compatible, but the code
> > compiles anyway and then misbehaves at runtime.
>
> FWIW if we do "some strange thing" we may end up shooting our own foot.
> Like:
>
> a.cc:
>
> #include <cstdio>
>
> extern "C"
> {
>         struct A { struct {} x; int a; };
>         void callback(void (*fn)(struct A *));
> }
>
> void f(struct A *p)
> {
>         std::printf("%d\n", p->a);
> }
>
> int main()
> {
>         callback(f);
> }
>
> b.c:
>
> #include <stdio.h>
>
> struct A { struct {} x; int a; };
> void callback(void (*fn)(struct A *))
> {
>         struct A foo = { .a = 42 };
>         fn(&foo);
> }
>
> This thing won't work with GCC because struct A will have different
> layouts in GNU C and C++.  Note that the C standard does not allow an
> empty struct at all (a pedantic C compiler should reject b.c as an empty
> struct violates the syntax rule of C).  But GNU C supports it as an
> extension.

Strictly speaking, a pedantic C compiler should issue a diagnostic. It
doesn't have to fail to compile.

$ gcc -pedantic b.c
b.c:3:12: warning: struct has no members [-Wpedantic]
   3 | struct A { struct {} x; int a; };
     |            ^~~~~~