Re: Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Pgsql Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE
Date: 2025-12-07 12:16:28
Message-ID: CAGECzQTZs4OeAwdAEa_uq=Qjoz_S3yOre9usNio8LBigEweiqw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 6 Dec 2025 at 21:40, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yeah. However, selecting different PG_PRINTF_ATTRIBUTE values for
> C and C++ mode seems to get the job done. I've confirmed the attached
> silences these warnings for me when mixing-and-matching gcc and clang.

I've definitely run into this myself a bunch of times. I'm wondering
if we should do this for more of these compiler features, e.g.
HAVE_TYPEOF is strictly wrong for C++ builds afaict[1].

[1]: https://www.postgresql.org/message-id/flat/CAGECzQR21OnnKiZO_1rLWO0-16kg1JBxnVq-wymYW0-_1cUNtg(at)mail(dot)gmail(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marcos Pegoraro 2025-12-07 14:22:27 Re: Initial COPY of Logical Replication is too slow
Previous Message jian he 2025-12-07 11:21:47 Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part