On 19/04/2024 12:36, Zachary Santer wrote:
On Fri, Apr 19, 2024 at 5:32 AM Pádraig Brady <p...@draigbrady.com> wrote:
env variables are what I proposed 18 years ago now:
https://sourceware.org/bugzilla/show_bug.cgi?id=2457
And the "resistance to that" from the Red Hat people 24 years ago is
listed on a website that doesn't exist anymore.
If I'm to argue with a guy from 18 years ago...
Ulrich Drepper wrote:
Hell, no. Programs expect a certain buffer mode and perhaps would work
unexpectedly if this changes. By setting a mode to unbuffered, for instance,
you can easily DoS a system. I can think about enough other reasons why this is
a terrible idea. Programs explicitly must request a buffering scheme so that it
matches the way the program uses the stream.
If buffering were set according to the env vars before the program
configures buffers on its end, if it chooses to, then the env vars
have no effect. This is how the stdbuf util works, right now. Would
programs that expect a certain buffer mode not set that mode
explicitly themselves? Are you allowing untrusted users to set env
vars for important daemons or something? How is this a valid concern?
This is specific to the standard streams, 0-2. Buffering of stdout and
stderr is already configured dynamically by libc. If it's going to a
terminal, it's line-buffered. If it's not, it's fully buffered.
Playing devil's advocate, I guess programs may be depending
on the automatic buffering modes set.
I guess the thinking is that it was too easy to perturb
the system with env vars, though you can already do that with LD_PRELOAD.
Perhaps at this stage we should consider stdbuf ubiquitous enough to suffice,
noting that it's also supported on FreeBSD.
I'm surprised that the LD_PRELOAD setting is breaking your ada build,
and it would be interesting to determine the reason for that.
cheers,
Pádraig
