Re: emacs-28 9c222b9: Port to C compilers that lack size-0 arrays

[Eli Zaretskii]

> branch: emacs-28
> commit 9c222b9c1a7f91497a37567b4d7de3a511fff069
> Author: Paul Eggert <eggert@cs.ucla.edu>
> Commit: Paul Eggert <eggert@cs.ucla.edu>
> 
>     Port to C compilers that lack size-0 arrays
>     
>     The C standard does not allow size-zero arrays, so redo struct
>     Lisp_Subr to not use size-zero arrays when native compilation is
>     not being used.  Formerly, the code was using size-zero arrays (a
>     GNU C extension) to avoid using memory unnecessarily when
>     HAVE_NATIVE_COMP is not defined.  Replace this hack with the
>     more-traditional hack of putting the relevant members inside
>     ‘#ifdef HAVE_NATIVE_COMP’.
>     * src/alloc.c (cleanup_vector, mark_object):
>     * src/comp.c (make_subr):
>     * src/data.c (Fsubr_native_lambda_list, Fsubr_native_comp_unit):
>     * src/eval.c (init_eval_once, funcall_lambda):
>     * src/lisp.h (SUBR_NATIVE_COMPILEDP, SUBR_NATIVE_COMPILED_DYNP)
>     (SUBR_TYPE):
>     * src/lread.c (Fload):
>     Conditionally compile with ‘#ifdef HAVE_NATIVE_COMP’ instead of
>     with ‘if (NATIVE_COMP_FLAG)’.  Redo members like native_comp_u[0]
>     to be plain native_comp_u.  Put all uses of these members inside
>     ‘#ifdef HAVE_NATIVE_COMP’.
>     * src/lisp.h (struct Lisp_Subr): Members native_comp_u,
>     native_c_name, lambda_list, type are now all ifdeffed out if
>     HAVE_NATIVE_COMP is not defined, instead of being size-zero
>     arrays.  All uses changed.
>     * src/pdumper.c (dump_subr, dump_cold_native_subr)
>     (dump_do_dump_relocation):
>     * src/comp.h (NATIVE_COMP_FLAG): Remove; no longer needed.

Paul, why did you install this large and non-trivial changeset on the
release branch without any discussion?  Please don't do that.  We have
already started the pretest.

How serious is the problem this attempts to solve, and what bad things
will happen if we release Emacs 28.1 without those changes?