From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0FF592581
	for <c-std-porting@lists.linux.dev>; Wed,  8 Feb 2023 13:57:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1675864632;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=5sbfF3GvESr2oavvh2b+TaZ91Y4mK1RCoM0MGaz3YVc=;
	b=ZPziAemjOP1dhj/vEsfSZ9PG0OdMtmT2PdBVMiR4ABm93D00DbulUF2KeXM7QQ3c1Jxn+L
	iKnSS0nkPv76Kj4lmUcXgPyie0Qbso777hHiMnjEYdpgiqeS+T/HBqbILQaVMAwhXrRlZW
	b2XGMxFjlsy+KQeExzBlsm9kgGA+1xs=
Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com
 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 us-mta-339-e4NOvY6sOTq4NX6ONGD1cA-1; Wed, 08 Feb 2023 08:57:10 -0500
X-MC-Unique: e4NOvY6sOTq4NX6ONGD1cA-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 54838384798C;
	Wed,  8 Feb 2023 13:57:10 +0000 (UTC)
Received: from oldenburg.str.redhat.com (unknown [10.2.16.7])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id A97EE40398A0;
	Wed,  8 Feb 2023 13:57:09 +0000 (UTC)
From: Florian Weimer <fweimer@redhat.com>
To: Armin Rigo <armin.rigo@gmail.com>
Cc: python-cffi@googlegroups.com,  c-std-porting@lists.linux.dev
Subject: Re: [python-cffi] cffi.FFI.cdef and implicit function declarations
References: <87a61oqxgi.fsf@oldenburg.str.redhat.com>
	<CAMSv6X0-VSeov_EwdVEg2n2HawDspnC9P+b1S-WZW-nRinEaGA@mail.gmail.com>
	<CAMSv6X1SYtqD1vHsom8s0xCbqF-K_9EJV4htti0mL9RyqFiyZQ@mail.gmail.com>
Date: Wed, 08 Feb 2023 14:57:08 +0100
In-Reply-To: <CAMSv6X1SYtqD1vHsom8s0xCbqF-K_9EJV4htti0mL9RyqFiyZQ@mail.gmail.com>
	(Armin Rigo's message of "Wed, 8 Feb 2023 13:18:13 +0100")
Message-ID: <87k00smf9n.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Precedence: bulk
X-Mailing-List: c-std-porting@lists.linux.dev
List-Id: <c-std-porting.lists.linux.dev>
List-Subscribe: <mailto:c-std-porting+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:c-std-porting+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain

* Armin Rigo:

> Hi again,
>
> On Wed, 8 Feb 2023 at 13:12, Armin Rigo <armin.rigo@gmail.com> wrote:
>> make the declared functions available to the C code.  A typical usage
>> is to say ffi.verify('#include <something.h>').  If you are getting an
>> "implicit function" warning from the C compiler, then this was not
>> done correctly.
>
> ...In other words, if changes to the C compiler replaces these
> warnings with errors, and this breaks old existing code, then that old
> code was broken in the first place for relying on that feature.  I
> don't think there is something to say about that specifically for
> CFFI's old verify() API.  I think the problem is the same as people will
> encounter with old, manually-written C code which was broken the same way.
> The fix is to add the missing #include in both cases.  For ffi.verify()
> it is added in the first argument, which is copied into the generated C code.

Okay, this is good to know.  Thank you for taking the time to explain
it.

Florian