Re: Build warning with meson and dtrace on Fedora 43

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