Using environment variables without leaking memory?

[Rich Felker]

On Thu, Oct 26, 2006 at 12:34:14PM -0400, Rob Landley wrote:
> On Thursday 26 October 2006 3:59 am, Rich Felker wrote:
> > On Tue, Oct 24, 2006 at 03:51:35PM -0400, Rob Landley wrote:
> > > Not actually all that hard to implement, really.  Why people have accepted 
> > > such a screwed up status-quo for 15 years (forget about Unix, why have the 
> > > _linux_ people accepted it?) is an open question.
> > 
> > I suspect the reason is a very good one: modifying the environment is
> > something you have to do only very rarely (i.e. only a small number of
> > programs do it, even if those few do it often), and any "fix" would
> > not be available on other systems, so writing programs dependent on
> > the fix would just mean more non-portable programs.
> 
> I really don't care about non-Linux systems anymore.  I just don't.  You can 
> run Linux on a laptop, cell phone, supercomputer cluster, you name it.  And 
> elsewhere Linux semantics are emulated (from Cygwin to the L in AIX5L).

But maybe you will the day someone unveils a system that's 1/4 the
size and complexity of Linux, twice the speed of Linux, and actually
has a guarantee of no vulns (like $1000 USD to anyone who finds a
privilege elevation bug), etc. Only caring about a single system leads
to a dead-end line of development where new things are never tried.

One could say exactly the same thing about people who write configure
scripts depending on GNU coreutils, GCC depending on FHS filesystem
structure, programs that require i386 assembly in order to run (hey,
until amd64 a few years ago, most people considered i386 the only
relevant platform, aside from embedded geeks.. :).

The point is things change. Any new system aiming not to suck will not
emulate every random GNU/Linux-ism out there; it will be streamlined.
The BSDs started sucking as soon as they decided to follow GNU and
Linux rather than being their own system.

> > Instead it's more 
> > practical just to write a solution that works everywhere, like
> > deferring modification of the environment until after you fork.
> 
> COBOL works everywhere too.  Doesn't make it a good idea.

But C+POSIX works everywhere and _is_ a good idea. Aside from the few
abominations invented in committee, like pthread, aio, and some of the
more obscure regex requirements, C and POSIX are very good standards
in that they standardize what was historical practice on traditional
systems when possible, and make minimal changes for the sake of
compatibility (which are usually easy to adopt into existing
implementations) when historical implementations disagree or when
there's an obvious deficiency.

Unfortunately you've run into one of the small places where they
screwed up. :(

Fortunately there are only a tiny number of programs that ever need to
modify the environment (sh and env are all that come to mind).

> > Of course no one's going to stop you from writing your own functions
> > for managing the environment via the "environ" var... :) That should
> > work everywhere too.
> 
> That's what I did.  Might post it here when it's debugged.

Great!

Rich