From nobody Sun Feb 12 10:09:37 2023 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PF39t33p3z3qW1Y for ; Sun, 12 Feb 2023 10:09:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PF39t0tnrz3mRr; Sun, 12 Feb 2023 10:09:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676196594; 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=LqbXgX7dlQGVjAGyiJdMJFKlmGlmixNWonrV2gR6fvE=; b=NE56X9EC6UrBug/buhODR0xhZj9zD/n78kk2KMW6Ca1vPbW1kjGT+ZbFzZvMPheWq3UliD NtW722QY5ZAqUENB1X72lPqBkLq/JJ2IhfvtJJD0uNNfaDJmNv3nDKQrV9PiMLEfxnLKdg EhHMX6wef/iUjLZdtSINJyH8GpRFOLUWYhK8HPE9i191SHYrIX2r5UpzOKJJBw8UFMR0JG 5sBDuFi7PCVsuO6s3dKiE7wi9UHXjEcZBfohtp7yW6h2VdBiCo6GEq0nHL6BiG0DZxYTuV 7zT6OETg75OTkqL+ft1CGDQXjF9Ws4QdkezNSEXcRPyCTO/9Z4v4GTsC7BYSTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676196594; 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=LqbXgX7dlQGVjAGyiJdMJFKlmGlmixNWonrV2gR6fvE=; b=iAW60mMrdXLh41Ybfkc/+Ca7jZXU0kXAA53SoIDeKjrzdBYdyeaeLR6TcqguLDqSKRFx+g HK5vDJvbuE6Cp2Fa2NMWGcSbayrUidKRr4JlzRnav0I0HLVvZ368OUy1/Nmz6p329ZwriP WRiQOJ2hc70fGD7O4iugxBgMe6c6676A024rUbRY4llYDuu2IS7/9QE+38kbJRsS0hRCrv YaYVAIYHdmQIjuTV6ZpNNjyYV0okH06Pejs1LhGSWmklKaJPBJ6OQqSWgr4cWn6NPfdvBy gJJxt/aAwYbvjgFnqXeKVZVmPbT8K85y2Ax4dipvWG5tiAN0cGsD+g0+k27baw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676196594; a=rsa-sha256; cv=none; b=bUActiOR/Catxd2raV2dzMUdH3zuzIgy/FvS2qJb0FoYFmwfGu4vcZrtCcBn6o4YGt0HwG 6x/iQAhTRvIWS2MHrG+qHg4LgUSwy7ogWUX09fniFyYjcxRPe8w3D/zAZ3nP3JWCCOV8ME bcUXXAP6j8pHuxyl3AQ2a99wS7yUWUuS5I7n/RRtMpM0ruzshqnK1+PwRZtkSsAwNVe8sR 1utiQM0D7oYy8veIw35iZ9+jXB+41b6jVq3xn1Jwza2SdRugLu+6npvNe3bOK8UnjLmdcF sdRQmWizw/w2F19eirTDbWDTi/agMG7Csr3X+zBne/T/38vbBmaRZIXXHDPa1g== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PF39s6LQXzgBD; Sun, 12 Feb 2023 10:09:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9A69A5BC14; Sun, 12 Feb 2023 11:09:52 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_9244E90D-E4E9-4177-857C-6BD074668938"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: editors/uemacs fails to biuld on 14.0-CURRENT 1400079 From: Dimitry Andric In-Reply-To: Date: Sun, 12 Feb 2023 11:09:37 +0100 Cc: andrew clarke , =?utf-8?B?Sm9zw6kgUMOpcmV6?= , FreeBSD Ports Message-Id: <8EA8CA09-BBD4-455A-8946-57A2755690B3@FreeBSD.org> References: <8aceaed7bb0323fc53143a8befd35170@mail.yourbox.net> <20230211111245.o3qjm3oyncivtipu@ozzmosis.com> To: Guido Falsi X-Mailer: Apple Mail (2.3731.400.51.1.1) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_9244E90D-E4E9-4177-857C-6BD074668938 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 11 Feb 2023, at 12:45, Guido Falsi wrote: >=20 > On 11/02/23 12:12, andrew clarke wrote: >> Hi Jos=C3=A9, >> On 2023-02-11 08:16:16, Jos=C3=A9 P=C3=A9rez (fbl@aoek.com) wrote: >>> Hi, >>> I get the following error when poudriere building editors/uemacs on >>> 14.0-CURRENT 1400079: >>> ../src/eval.c:1483:10: error: incompatible pointer to integer = conversion >>> returning 'void *' from a function with result type 'int' = [-Wint-conversion] >>> return NULL; >>> ^~~~ >>> /usr/include/sys/_null.h:34:14: note: expanded from macro 'NULL' >>> #define NULL ((void *)0) >>> ^~~~~~~~~~~ >> ... >>> Stop. >>> make: stopped in /usr/ports/editors/uemacs >>>=20 >>> Is this known? >> The MicroEMACS source code was all written in vintage K&R style. = Evidently >> newer versions of Clang increasingly have a problem with this, which = I >> guess is unsurprising since the minimum C standard Clang is designed = for is >> probably C89/C90. >> In the K&R days NULL was #defined as 0, so a function returning an = int >> could correctly return NULL. That changed with C89. >> I'll admit it's a bit strange Clang has decided to clamp down on this >> some 33 years later. >> I don't currently have easy access to a FreeBSD machine running = clang-15, >> so can't supply a patch yet, though easiest fix (for now) may be to = build >> uemacs with devel/llvm13 (or maybe devel/llvm14) on FreeBSD 14+. >> cd /usr/ports/editors/uemacs >> CC=3Dclang-13 make >> (untested) >> Longer term, I'm not sure what the best solution is. I wouldn't = expect >> Clang (or GCC for that matter) to keep supporting uemacs' K&R style C = code >> forever, but converting it all to C90 syntax would be a laborious = task. >> Maybe there are tools for it. > As far as I understand what happened is that a default was changed, = -Wint-conversion is now on by default. >=20 > So regarding this wouldn't forcing a flag to disable it again be = enough? >=20 > Obviously fixing the code is better whenever possible, but if this = code is not fixable due to age, changing flags should be ok. >=20 > Something like -Wno-error=3Dint-conversion or -Wno-int-conversion = should make the error go away. Same with similar issues with this code. >=20 > I'm not advocating doing this in general. In fact patching the code to = not cause these errors should be the solution, but for old code that is = not going to change upstream, maybe disabling the warnings is the = correct fix. To give some background on this: at some point during the last year, there were a few commits (see [1], [2] and [3]) to clang's main branch, which basically turned pre-C99 constructs such as implicit function declarations and implicit integer conversions and declarations into errors by default. This was because C99 and later C standards really don't support these features anymore, and everybody pretending to write programs to these standards should fix their code. (Also, keep in mind that since a few years, both clang and gcc default to -std=3Dgnu17, so these warnings and/or error messages can triggered = if you *don'* explicitly specify any -std=3D option yourself.) However, quite soon after these warnings were 'upgraded' to errors, Micha=C5=82 G=C3=B3rny posted a topic on LLVM's Discourse [4], where he = noted that many programs fail to explicitly specify any C standard while compiling, and this leads to all kinds of problems. For example, configure scripts might fail to detect some features, when they attempt to compile a small test program, but it errors out, not because the feature is unavailable, but because of implicit function declarations or implicit integer declarations. After some discussion on that topic, it was decided to downgrade the implicit integer and function declaration errors back to warnings again, and this was committed just before 15.0.1 [5]. Note, the -Wint-conversion warning is still an error, and it is suprising how often integers and pointers are blindly converted into each other. (Sometimes it seems like a miracle that any software works...) Also, for clang 16 and later, the implicit integer and function declaration errors will still be enabled, so programs pretending to be C99 will have to be fixed. However, for most old programs for which there is no real upstream anymore, or whose upstream doesn't care about upgrading from K&R C, there is a simple fix. Just compile these with -std=3Dgnu89, which is = the most compatible standard for such older software. tl;dr: * old software breaking with -Wimplicit-function-declaration and -Wimplicit-int errors can be fixed by setting USE_CSTD=3Dgnu89 (or whatever is necessary to make it use -std=3Dgnu89). * software breaking with -Wint-conversion should ideally have their integer-to-pointer or pointer-to-integer conversions fixed, but otherwise the error can be silened with -Wno-int-conversion. -Dimitry [1] https://github.com/llvm/llvm-project/commit/7d644e1215b3 [2] https://github.com/llvm/llvm-project/commit/2cb2cd242ca0 [3] https://github.com/llvm/llvm-project/commit/7068aa98412a [4] = https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror= -implicit-function-declaration/65213 [5] https://github.com/llvm/llvm-project/commit/c0141f3c300f --Apple-Mail=_9244E90D-E4E9-4177-857C-6BD074668938 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCY+i64QAKCRCwXqMKLiCW o6mbAKDap9LXNbVwHtl3Z7QB3FiHQI1dfwCeMU79rx0jGmEIsc5KZsNJBEhk0kk= =n1CA -----END PGP SIGNATURE----- --Apple-Mail=_9244E90D-E4E9-4177-857C-6BD074668938--