From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 01:21:34 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 24A7316A421 for ; Wed, 11 Jul 2007 01:21:34 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id 0694213C465 for ; Wed, 11 Jul 2007 01:21:34 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn07.u.washington.edu (hymn07.u.washington.edu [140.142.8.53]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6B1LX8T007361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2007 18:21:33 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn07.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6B1LXCV021048 for ; Tue, 10 Jul 2007 18:21:33 -0700 X-Auth-Received: from [192.55.52.3] by hymn07.u.washington.edu via HTTP; Tue, 10 Jul 2007 18:21:33 PDT Date: Tue, 10 Jul 2007 18:21:33 -0700 (PDT) From: youshi10@u.washington.edu To: current@freebsd.org In-Reply-To: <94B3BCF3-D490-48A5-8488-2E931E30C07B@mac.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.10.180536 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: 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 01:21:34 -0000 On Tue, 10 Jul 2007, Chuck Swiger wrote: > 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. Ok, thanks for the explanation :). >> #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 Ok :). -Garrett