Re: HAVE_FAST_UNALIGNED_ACCESS

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Mattias Engdegård <mattias.engdegard@gmail.com>,
>   vibhavp@gmail.com,
>   rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 01 Apr 2023 17:17:07 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > IOW, "best engineering practices" are for master; on the release
> > branch, using existing code proven by time takes precedence, because
> > our ability to predict consequences is limited.
> 
> This problem is not about engineering practices, but basic program
> correctness.  Look at the GCC bug tracker: every release, a program
> that relies on this undefined behavior becomes subtly broken, a bug
> is filed against GCC, and is closed by the GCC developers, stating
> that this behavior is unsupported.
> 
> Emacs 29 has been in development for less than three years... not nearly
> long enough to be sure no subtle miscompilations have taken (or will
> take) place.
> 
> If that's ``proven by time'', then so is this:
> 
> null_terminate (buffer, size)
>   char *buffer;
> {
>   buffer[size] = '\0';
> }
> 
> It might work for a few months, or a year, then suddenly break with a
> new compiler release, or perhaps a change to malloc, or something else.

I'm still unconvinced, and I said already what will have a chance of
convincing me: a specific report about a problem this particular code
causes on a specific existing platform we support in Emacs 29 and with
a specific compiler.