Re: 'char **environ' woes with cygwin

[Michael Elizabeth Chastain <chastain at cygnus dot com>]

> That doesn't seem equivalent to the code that uses environ.  I don't
> understand what the code is actually trying to do, but it seems
> incredibly ill-advised if it is relying on `environ' being in the heap
> somewhere.

Cheesy ascii art coming up ...


					     sbrk(0) ->	+-------+
							|	|
							| heap	|
    							|	|
     sbrk(0) ->	+-------+				+-------+
		|	|				|	|
		|  ...  |				|  ...	|
		|	|				|	|
    &environ ->	|environ|		    &environ -> |environ|
		|	|				|	|
		|  ...	|				|  ...	|
		+-------+				+-------+

  extern char **environ;	       extern char **environ;
  char *lim = (char *) sbrk(0);        char *lim = (char *) sbrk(0);
  space_at_cmd_start = (long) \        long space_now = lim - (char *) &environ;
    (lim - (char *) &environ);         long space_diff = \
    					  space_now - space_at_cmd_start;



Note that this code uses &environ.  It never uses the *value* of environ,
just its address.  As far as this code is concerned, "environ" is just a
variable that is guaranteed to be in the data segment.

If you run gdb as "gdb --statistics", then you will see "space_now"
and "space_diff" printed after each command.  The initial "startup size"
is bogus because &environ can be anywhere in the data segment.

"space_now" - "space_at_cmd_start" is equal to the amount of memory that's
been allocated from sbrk.  It would be simpler to compute this directly
and leave &environ out of the picture.  It would also eliminate the
crufty pointer arithmetic between the brk section and the data section.

Michael