Re: Build warning with meson and dtrace on Fedora 43

> So "avoid multiword type names" is both too general and not enough
> to keep out of trouble. [...] I'm inclined to write something like
> "Use only system-supplied type names, e.g., write uint64_t not uint64;
> macOS' dtrace rejects the latter. Also avoid "long long int", as
> SystemTap's dtrace fails on that specific spelling."

I've
rewritten the probes.d note along those lines and kept ssize_t/size_t
for the smgr probes (system-supplied, matching md.c).

Updated patch attached.

ср, 29 июл. 2026 г. в 20:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> writes:
> > On the probes.d note: it originally named Mac OS X 10.5 (e04810e8c4).
> > The concrete complaints from that era were about uintptr_t / uint32_t
> > and about needing #define rather than typedef for our PG aliases
> > (Robert Lor).
>
> I poked at this some more. On macOS Tahoe, both examples called out
> in the current text (uintptr_t, uint32_t) work fine, as does "long
> long int", as does uint64_t, but not uint64. On Red Hat platforms at
> least as far back as RHEL 9 and as late as Fedora 43, "long long int"
> doesn't work (matching the buildfarm reports), but "long int" does,
> and so does "unsigned int", and so does "long long" (!), and so do
> both uint64_t and uint64.
>
> So "avoid multiword type names" is both too general and not enough
> to keep out of trouble. It's not clear to me that we can come up
> with a simple rule of thumb. We clearly should recommend against
> using non-system-supplied type names, since it looks like macOS
> has a whitelist of valid type names. But the Linux implementation
> seems to be missing specifically "long long int".
>
> I'm inclined to write something like "Use only system-supplied type
> names, e.g., write uint64_t not uint64; macOS' dtrace rejects the
> latter. Also avoid "long long int", as SystemTap's dtrace fails on
> that specific spelling." We can add other problems as we hit them,
> but let's not warn people away from cases we've not tested.
>
> regards, tom lane
>