all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: emacs-28 9c222b9: Port to C compilers that lack size-0 arrays
@ 2021-12-03  8:16 Eli Zaretskii
  2021-12-03 16:46 ` Paul Eggert
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2021-12-03  8:16 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

> 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?



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-12-04 11:24 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-03  8:16 emacs-28 9c222b9: Port to C compilers that lack size-0 arrays Eli Zaretskii
2021-12-03 16:46 ` Paul Eggert
2021-12-03 18:29   ` Eli Zaretskii
2021-12-03 19:42     ` Paul Eggert
2021-12-03 20:01       ` Eli Zaretskii
2021-12-03 23:32         ` Paul Eggert
2021-12-04  7:35           ` Eli Zaretskii
2021-12-04 10:47             ` Stefan Kangas
2021-12-04 11:24               ` Po Lu
2021-12-04  0:37         ` Po Lu

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.