Re: Dead code in ps_status.c

Hi Thomas,

On Mon, Nov 17, 2025 at 12:54:44PM +1300, Thomas Munro wrote:
> On Tue, Nov 11, 2025 at 11:04 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> > https://www.postgresql.org/message-id/68adbcd3.500a0220.8d4c9.9460%40mx.google.com
> >
> > Sorry I missed this.  I had some trouble with your messages being
> > deleted as spam, which I've hopefully fixed now...

(Sorry about that, I think I fixed it now (after Alvaro mentioned it
again to me at pgconf.eu). Ironically, your previous mail from November
11 was flagged as spam by my provider so I didn't see it until now,
either)

> > -#elif defined(__linux__) || defined(__sun) || defined(__darwin__)
> > +#elif defined(__linux__) || defined(__sun) || defined(__darwin__) ||
> > defined(__GNU__)
> >
> > Would __gnu_hurd__ be a better bet, less confusable with GNU userspace
> > stuff?  I think these platform macros might come from this file in
> > GCC:
> >
> > https://github.com/gcc-mirror/gcc/blob/faf7053346110cbd11fb22ff75f56a964047b19c/gcc/config/gnu.h#L30
> >
> > But maybe not only there, if __hurd__ (as removed by d2ea2d31)
> > actually worked...
> 
> I failed to locate a definitive source in a manual or porting guide or
> such, but I see patches making the same change in other projects in
> their mailing lists[1], so it seems that  __GNU__ is indeed their
> preferred way of detecting a GNU/Hurd (or IIUC 100% "GNU") system, and
> it's certainly not defined on my Debian GNU/Linux machine according to
> GCC and Clang. 

Yeah, __GNU__ is the usual way to distinguish that, I didn't even know
about __gnu_hurd__ until I looked up the same file above when I wrote
the patch...

> So although it was slightly confusing to this human, being used to
> seeing __GNUC__ and similar, it doesn't appear to be confusing to
> computers.
> 
> Pushed, and back-patched to 16, where it applied without problems.

Thanks!

> The REL_{14,15}_STABLE branches don't have commit d2ea2d31.  I thought
> about doing s/__hurd__/__GNU__/ instead, but it actually said:
> 
> #elif (defined(BSD) || defined(__hurd__)) && !defined(__darwin__)
> #define PS_USE_CHANGE_ARGV
> 
> The right thing to do might be to remove it from there, define
> PS_USE_CLOBBER_ARGV like in the newer branches and also apply the
> second hunk about padding strategy (in other words: be exactly like
> GNU/Linux), but I can't test that.  If 14 and 15 are still interesting
> to you, let me know if that makes sense and works as expected,
> otherwise I'll assume you just want to let sleeping dogs lie.

I mentioned that in a follow-up[0] to my original mail that you
apparently did not see eiter:

|By the way, on the back branches from 13-15 (before the above commit)
|process title changes don't work either, presumably because __hurd__ (as
|opposed to __GNU__ and __gnu_hurd__) has not been defined on GNU/Hurd
|for ages (or ever?), see
|https://github.com/gcc-mirror/gcc/blob/master/gcc/config/gnu.h#L25
|
|So in case this get backpatched, I think it should be changed to
|PS_USE_CLOBBER_ARGV there as well.

So yeah, I think those would be useful to fix. If you have a patch, I am
happy to test it, or I can come up with one (but not sure I manage this
week).


Thanks,

Michael

[0] https://www.postgresql.org/message-id/68add009.170a0220.16b3ca.d01e%40mx.google.com