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

On 11/02/23 12:12, andrew clarke wrote:
> 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.
> 
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 <madpilot@FreeBSD.org>