Hi Joseph,
> On Tue, 25 Nov 2025, Rainer Orth wrote:
>
>> However, I think find that defining __PID_TYPE__ alone is still useful
>> since it follows a well-known and easily understandable pattern, even if
>> its use is limited. This is what the following revision does, also
>> clarifying the context for __PID_TYPE__.
>
> I don't think it's a good idea; the pattern is that predefined macros are
> for GCC-provided headers or user code, and this one isn't appropriate in
> either place, since no GCC-provided header uses this type and user code
> should use <sys/types.h>.
>
> We have an option -fbuilding-libgcc to define extra internal macros that
> are only relevant for building GCC's target libraries, but this one isn't
> relevant there either. And I don't think a new option
> -fbuilding-gcc-testsuite would be a good idea for this one, given that
> there's no actual need for this macro in the testsuite because typeof
> (__builtin_fork ()) can be used instead.
understood. So what's the best way forward? Drop __PID_TYPE__ and
replace its uses with the typeof construct? Or drop PID_TYPE
documentation, too?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
