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

On 11 Feb 2023, at 12:45, Guido Falsi <madpilot@FreeBSD.org> wrote:
> 
> 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.

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=gnu17, so these warnings and/or error messages can triggered if
you *don'* explicitly specify any -std= option yourself.)

However, quite soon after these warnings were 'upgraded' to errors,
Michał Górny 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=gnu89, 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=gnu89 (or
  whatever is necessary to make it use -std=gnu89).
* 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