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 59EE4945D
	for <c-std-porting@lists.linux.dev>; Wed,  8 Feb 2023 10:10:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1675851043;
	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:
	 content-transfer-encoding:content-transfer-encoding;
	bh=6xqEbu1LyGmVwHMSK76wDOP304yGUmDeN/OYIWeo8ko=;
	b=jMy21DlcO89BHok9AeMz3G8aueeQBz7XPIWdxQSlKDlaI6w654VetrClrvJIwYT86WzQAz
	U0d3FuxupwvASdR/xZO03Cfw2ogKqIxmecNqVdw+OjiYXYZ8vr8mk6RHO8v5SNrXmyY5WK
	voiAUNRnppmjKzeUkbcgbkTf6dwuNuE=
Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com
 [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 us-mta-25-CISKfoD0Ppe4XlPC-zQhdw-1; Wed, 08 Feb 2023 05:10:39 -0500
X-MC-Unique: CISKfoD0Ppe4XlPC-zQhdw-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 721F3101A521;
	Wed,  8 Feb 2023 10:10:39 +0000 (UTC)
Received: from oldenburg.str.redhat.com (unknown [10.2.16.7])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id C56F540C83B6;
	Wed,  8 Feb 2023 10:10:38 +0000 (UTC)
From: Florian Weimer <fweimer@redhat.com>
To: python-cffi@googlegroups.com
Cc: c-std-porting@lists.linux.dev
Subject: cffi.FFI.cdef and implicit function declarations
Date: Wed, 08 Feb 2023 11:10:37 +0100
Message-ID: <87a61oqxgi.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.1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

We are trying to build Fedora with a compiler that does not support
implicit function declarations:

  <https://fedoraproject.org/wiki/Changes/PortingToModernC>
  <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>

Gentoo is doing something simlar:

  <https://wiki.gentoo.org/wiki/Modern_C_porting

While investigating a false positive from our tester triggered by the
python-cffi testsuite, I noticed a curiousity with cdef: it does not
inject the specified prototype into the generated C stub.  This means
that unless Python.h happens to include a header with a function
declaration, an implicit declaration is the result.

For example, this snippet:

=E2=80=9C
import cffi

ffi =3D cffi.FFI()
ffi.cdef("int puts(const char *);")
ffi.cdef("const char *getenv(const char *);")
ffi.cdef("const char *gnu_get_libc_release(void);")
lib =3D ffi.verify()
lib.puts(lib.getenv(b"TERM"))
lib.puts(lib.gnu_get_libc_release())
=E2=80=9D

prints this on x86 32-bit:

=E2=80=9C
vt100
stable
=E2=80=9D

But the call to gnu_get_libc_release() crashes on x86-64 64-bit because
the implicit declaration has return type int, and the pointer is clipped
to 32 bits.

This not an issue if the function returns int, though.  And to support
implicit declarations, many POSIX interfaces return int anyway, so it
just works, although and ugly warning is printed on first use.

This will stop working once the compiler no longer accepts such implicit
function declarations.  How common is such use of cdef?  Do we need to
worry about it?  Is there something we need to do as part of the new
compiler rollout?

Thanks,
Florian