Re: Adding putenv/setenv functionality to libiberty (for fixincl)

[Jeffrey A Law <law at upchuck dot cygnus dot com>]

  In message <199905292122.OAA14008@aldrington.ppp.cs.sfu.ca>you write:
  > My feeling here is that I have unearthed a portability issue in fixincl.
Agreed.

  > While Unix98, SunOS 4.x and SVR4 machines have putenv as described in
  > Bruce's comment, it would appear that glibc systems (e.g. Linux) and
  > BSD systems may not.  For example, Apple's Darwin OS, a BSD-derived
  > system, uses the following implementation for putenv:
And thus we have 3 solutions:

  1. Always use putenv from libiberty, using the semantics provided by
     libiberty (not as easy as it might sound since putenv is only included
     in libiberty if it's not in the system C library).

  2. Avoid putenv entirely.  Possibly settling on setenv if it has better
     defined semantics.

  3. Support both variants of putenv (yuk).

I'd lean towards #2.  It seems the safest assuming that the behavior of
setenv hasn't changed over time.


[ ... ]
  > Let's see what happens when I run it on some machines I have access to:
  > 
  > redhat5% uname -m -r -s
  > Linux 2.0.36 i586
  > redhat5% testputenv
  > putenv copies
  > 
  > sunos% uname -m -r -s
  > SunOS 4.1.3 sun4
  > sunos% testputenv
  > putenv aliases
  > 
  > solaris% uname -m -r -s
  > SunOS 5.6 sun4u
  > solaris% testputenv
  > putenv aliases
  > 
  > The only BSD-style system I have access to is a NEXTSTEP machine, and
  > that doesn't have putenv at all. (But I have Apple's (BSD derived) Darwin
  > OS source to check, as we saw earlier.)
On 4.4bsd (and likely its deratives) putenv copies.

jeff