On Tue, 25 Nov 2025, Rainer Orth wrote: > 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?
Drop __PID_TYPE__ and replace its uses with the typeof construct. -- Joseph S. Myers [email protected]
