Re: Build warning with meson and dtrace on Fedora 43

> This seems to me to be a fundamentally broken, hence short-lived
> workaround. I think we need another way. As you mention upthread,
> we document that system-header types such as ssize_t should not be
> used in probes.d because "they cause compilation errors on macOS".
> But I tried it just now and it compiles fine on current Tahoe.
> Maybe that note is obsolete?

Agreed that "long" was only papering over SystemTap's parser. v2 uses
the real call-site types instead:
```
probe smgr__md__read__done(..., int, ssize_t, size_t);
probe smgr__md__write__done(..., int, ssize_t, size_t);
```

nbytes is ssize_t (and can be negative: we fire the probe before the
nbytes < 0 check). The "bytes requested" argument is
size_this_segment - transferred_this_segment, which is size_t.
ssize_t, ssize_t would also silence SystemTap, but wouldn't match md.c.

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). da6c4f6ca88 only rebranded the wording to "macOS 10.5";
later ff43b3e88ec dropped the "10.5" while touching the nearby bool
#define, without re-checking the restriction. ssize_t and size_t, by
contrast, are first-class types in Apple's DTrace typedef tables.
Your Tahoe result fits that; I don't have a Mac here to re-check
myself. I've revised the note to warn against multi-word types like
"long long int" (what SystemTap rejects) rather than blanket-banning
system typedefs.

Verified on Fedora 43 / systemtap-sdt-devel: unpatched probes.d still
gets the pyparsing fallback warning; with ssize_t, size_t both
dtrace -C -h and meson probes.h generation are clean, as is a full
configure --enable-dtrace build.

---
Regards,
Rachitskiy Andrey

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

> Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> writes:
> > Hi, Laurenz!
> > Thanks for the report. I tried to fix the patch in the attachment.
>
> BF animals caiman, midge, tayra, timberworm are all complaining about
> this. In keeping with meson's general habit of verbose yet largely
> useless configuration reporting, it's impossible to tell exactly what
> OS versions those are running, though their possibly-outdated BF
> metadata claims recent Red Hat versions. However, I also reproduced
> the warning with an autoconf build on current Fedora 43 / x86_64.
>
> > Commits ca326e903d and 1f8c504e308 widened the byte-count arguments of
> > smgr__md__read__done and smgr__md__write__done to "long long int".
> > SystemTap's dtrace(1) pyparsing grammar rejects that multi-word type and
> > falls back with a warning (misreported near the previous probe). Use
> > "long" instead, which matches ssize_t on our LP64 DTrace platforms and
> > is already used elsewhere in probes.d.
>
> This seems to me to be a fundamentally broken, hence short-lived
> workaround. I think we need another way. As you mention upthread,
> we document that system-header types such as ssize_t should not be
> used in probes.d because "they cause compilation errors on macOS".
> But I tried it just now and it compiles fine on current Tahoe.
> Maybe that note is obsolete?
>
> regards, tom lane
>