Re: HEADS UP: getenv() and family API change

On Tue, 10 Jul 2007, Chuck Swiger wrote:

> On Jul 10, 2007, at 5:05 PM, youshi10_at_u.washington.edu wrote:
>> On Wed, 11 Jul 2007, Erik Trulsson wrote:
>>> Not the pointer, but the string it points to can be put into read-only
>>> memory.
>>> 
>>> Example:
>>> 
>>> static char *s = "PATH=/bin";
>>> static char *t = "PATH=/bin";
>>> 
>>> 
>>> Here both 's', and 't' can point into read-only memory where the string
>>> "PATH=/bin" has been placed.  Not only that, they may point to the same
>>> place, i.e. there need only be one copy of the string "PATH=/bin" in
>>> the program (but there may be two distinct copies if the compiler does not
>>> coalesce identical string constants.)
>>> 
>>> 
>>> If on the other hand you use
>>> 
>>> static char s[] = "PATH=/bin";
>>> static char t[] = "PATH=/bin";
>>> 
>>> 
>>> Then 's' and 't' are no longer pointers to a string constant, but arrays
>>> that are initialized with the string "PATH=/bin".  These arrays are
>>> modifiable and distinct - i.e. there will be (at least) two copies of the
>>> string "PATH=/bin" in memory.
>>> 
>>> 
>>> 
>>> 
>>> --
>>> <Insert your favourite quote here.>
>>> Erik Trulsson
>>> ertr1013_at_student.uu.se
>> 
>> I'm confused what you're referring to as RO memory -- I thought that only 
>> const applied in this case:
>
> It means that the string can be placed in a section of the executable file 
> which is loaded with read-only memory protection set so that attempts to write 
> to it fail; ELF calls this .rodata in contrast to the normal .bss and .data 
> sections which contain (respectively) zero-filled memory and preinitialized but 
> writable data.

Ok, thanks for the explanation :).

>> #include <stdio.h>
>> 
>> int main () {
>> 
>>     static char *s = "PATH=/bin";
>>     s = "PATH=/sbin";
>> 
>>     printf("%s\n", s);
>> 
>>     return 0;
>> 
>> }
>> 
>> filc9175[409]% gcc -o try try.c
>> filc9175[410]% ./try
>> PATH=/sbin
>> 
>>       Doesn't static (in terms of variables) only state that the memory 
>> address and values are not to be released to the heap again after the 
>> function scope exits?
>
> static implies that the variables are held in memory address space which is 
> made permanently available, either from pages mapped in from the executable 
> file (that's the .data segment) or from zero-filled heap pages (.bss), rather 
> than going away after the enclosing function has returned.  The default 
> automatic scope actually typically uses the stack, not the heap...
>
> -- 
> -Chuck

Ok :).

-Garrett