Horton
Menu

Re: Centralised architecture detection

Nico Williams <nico@cryptonector.com>

View thread
From: Nico Williams <nico@cryptonector.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>, Lukas Fittl <lukas@fittl.com>, John Naylor <johncnaylorls@gmail.com>, Bryan Green <dbryan.green@gmail.com>
Date: 2026-06-03T21:21:14Z
Lists: pgsql-hackers 
On Wed, Jun 03, 2026 at 05:08:55PM -0400, Tom Lane wrote:
> I wrote:
> > Nathan Bossart reminded me of this thread after I'd independently
> > rediscovered the same thing [1].  I agree with standardizing on
> > just one spelling of these CPU-type macros.  But I wonder why we
> > should invent our own instead of standardizing on gcc's spellings
> > (that is, __x86_64__ etc).  The amount of code churn required for
> > this patch would drop drastically if we did it that way.  And I
> > suspect it would be less likely that we'd need to fixup future patch
> > submissions than if we have a homegrown standard.
> 
> Concretely, I'm imagining that we'd do more or less the attached in
> c.h, and then the rest of the work would just be to remove the
> not-very-large number of references to the alternative CPU symbols.

Can a pre-processor make it an error for users to define __ macros?

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix CPU-identification macros for RISC-V.

  2. Clean up inconsistencies in CPU-identification macros.