On 11/02/23 12:12, andrew clarke wrote:
Hi José,
On 2023-02-11 08:16:16, José Pérez (f...@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
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=clang-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.
So regarding this wouldn't forcing a flag to disable it again be enough?
Obviously fixing the code is better whenever possible, but if this code
is not fixable due to age, changing flags should be ok.
Something like -Wno-error=int-conversion or -Wno-int-conversion should
make the error go away. Same with similar issues with this code.
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.
--
Guido Falsi <madpi...@freebsd.org>
