On Mon, Mar 18, 2024 at 10:06 AM Christophe Pettus <xof@thebuild.com> wrote:
> > On Mar 17, 2024, at 13:33, Andrew Dunstan <andrew@dunslane.net> wrote:
> > That seems a little shortsighted. If other libc implementations find it appropriate to have similar macros why
shouldthey be different?
>
> It's a philosophical argument against checking for particular libc implementations instead of particular features.
I'mnot unsympathetic to that argument, but AFAICT there's no clean way of checking for this by examining feature
#defines.
I like their philosophy, and I like their FAQ. Down with software
monocultures, up with standards and cooperation. But anyway...
I wondered for a moment if there could be a runtime way to test if
we'd broken stuff, but it seems hard without a way to ask the runtime
linker for its search path to see if it has any pointers into the
environment. We can't, that "env_path" variable in dynlink.c is not
accessible to us by any reasonable means. And yeah, this whole thing
is a nasty invasive hack that harks back to the 80s I assume, before
many systems provided a clean way to do this (and some never did)...
Hmm, I can think of one dirty hack on top of our existing dirty hack
that might work. I feel bad typing this out, but here goes nothing:
In save_ps_display_args(), we compute end_of_area, stepping past
contiguous arguments and environment variables. But what if we
terminated that if we saw an environment entry beginning "LD_"? We'd
still feel free to clobber the memory up to that point (rather than
limiting ourselves to the argv space, another more conservative choice
that might truncate a few PS display messages, or maybe not given the
typical postmaster arguments, maye that'd work out OK), and we'd still
copy the environment to somewhere new, but anything like "LD_XXX" that
the runtime linker might have stashed a pointer to would remain valid.
/me runs away and hides