Re: disallow big-endian on aarch64

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, pgsql-hackers(at)postgresql(dot)org, andres(at)anarazel(dot)de
Subject: Re: disallow big-endian on aarch64
Date: 2025-10-03 06:37:02
Message-ID: 21b645b0-af32-4f73-b9f5-163075ed95bb@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 02.10.25 23:31, Nathan Bossart wrote:
> On Thu, Oct 02, 2025 at 05:08:42PM -0400, Tom Lane wrote:
>> Nathan Bossart<nathandbossart(at)gmail(dot)com> writes:
>>> The benefit is that we can safely assume little-endian in AAarch64-specific
>>> code, and on the off-chance that someone tries to build Postgres in an
>>> AArch64/big-endian environment, we aren't pretending to support it.
>> Is that actually a meaningful benefit, ie can we remove any code
>> anywhere?
> I'm not aware of existing code that is broken, but some of the stuff I'm
> intending to commit soon to optimize hex_{encode,decode} might be sensitive
> to endianness. In any case, I don't think it's outside the realm of
> possibilities for architecture-specific code.

As a future direction, in cases like this I think it would be better to
write a static assertion. Then the check is self-contained in the C
code, perhaps next to the code it's trying to protect, perhaps with a
comment, and doesn't have to be maintained in some far-away configure
shell script.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2025-10-03 06:52:05 Re: Report bytes and transactions actually sent downtream
Previous Message Alexander Korotkov 2025-10-03 06:31:33 Re: VM corruption on standby