From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [IPv6:2001:470:683e::1]) by sourceware.org (Postfix) with ESMTPS id A15923858024 for ; Fri, 27 Jan 2023 14:30:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A15923858024 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1674829842; bh=lMbrM0YD1a5lGRszfjR/5u6sEFopGkrFt70OptbKXho=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=exnjQj/EqXf7uxeW759OACQIkYsrK+D7jHtAhm3bwVJRvgPJpyLbokxGLOeLGs7xO fTSsHNouD7kAYxJvR/tk/yRkufKWEa7WfG8RhsJHgWJ/sVJVijMLqhBbFSpTzY6bhu qXG0+KhBpqkjGK26S1341X/6ytjdfV59v1fEEJTA= Received: from [IPv6:240e:358:11ca:f700:dc73:854d:832e:2] (unknown [IPv6:240e:358:11ca:f700:dc73:854d:832e:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 9B25F668E6; Fri, 27 Jan 2023 09:30:40 -0500 (EST) Message-ID: Subject: Re: Correct way to provide a C callback function nside C++ From: Xi Ruoyao To: Jonathan Wakely , Pepe Cc: gcc-help@gcc.gnu.org Date: Fri, 27 Jan 2023 22:30:33 +0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.3 MIME-Version: 1.0 X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROM_SUSPICIOUS_NTLD,KAM_SHORT,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_PDS_OTHER_BAD_TLD autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 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 struct A { struct {} x; int a; }; void callback(void (*fn)(struct A *)) { struct A foo =3D { .a =3D 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. > The relevant GCC bug about this nonconformance is > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D2316 (and will probably > never be fixed, because it would break far too much code). Perhaps we should document it as an extension as well and add a warning option... But this will be the lowest priority even if we'd spend our time for the job. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University