From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 00:37:54 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4C2016A41F for ; Wed, 11 Jul 2007 00:37:54 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id BFD2313C458 for ; Wed, 11 Jul 2007 00:37:54 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (Postfix) with ESMTP id 83C4FB6A0CD; Tue, 10 Jul 2007 17:37:54 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 6DAC94008B; Tue, 10 Jul 2007 17:37:54 -0700 (PDT) X-AuditID: 11807126-a20cdbb0000007dd-6e-4694266203a1 Received: from [17.214.13.96] (int-si-a.apple.com [17.128.113.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id 4E9CC4004E; Tue, 10 Jul 2007 17:37:54 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94B3BCF3-D490-48A5-8488-2E931E30C07B@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 10 Jul 2007 17:37:53 -0700 To: youshi10@u.washington.edu X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: current@freebsd.org Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 00:37:54 -0000 On Jul 10, 2007, at 5:05 PM, youshi10@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. >> >> >> >> >> -- >> >> Erik Trulsson >> ertr1013@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. > #include > > 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