Re: editors/uemacs fails to biuld on 14.0-CURRENT 1400079

From: andrew clarke <mail_at_ozzmosis.com>
Date: Sat, 11 Feb 2023 11:12:45 UTC
Hi José,

On 2023-02-11 08:16:16, José Pérez (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
>
> 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.

Thanks,
Andrew