Date: Sun, 12 Feb 2023 11:09:37 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Guido Falsi <madpilot@FreeBSD.org> Cc: andrew clarke <mail@ozzmosis.com>, =?utf-8?B?Sm9zw6kgUMOpcmV6?= <fbl@aoek.com>, FreeBSD Ports <ports@freebsd.org> Subject: Re: editors/uemacs fails to biuld on 14.0-CURRENT 1400079 Message-ID: <8EA8CA09-BBD4-455A-8946-57A2755690B3@FreeBSD.org> In-Reply-To: <aac4282d-da2a-17dc-28cd-f4b511359c96@FreeBSD.org> References: <8aceaed7bb0323fc53143a8befd35170@mail.yourbox.net> <20230211111245.o3qjm3oyncivtipu@ozzmosis.com> <aac4282d-da2a-17dc-28cd-f4b511359c96@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <madpilot@FreeBSD.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8EA8CA09-BBD4-455A-8946-57A2755690B3>