From: "Mark E." To: djgpp-workers AT delorie DOT com Date: Mon, 28 May 2001 16:00:13 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: confstr implementation Message-ID: <3B12760D.23812.119949F@localhost> In-reply-to: <2110-Mon28May2001094428+0300-eliz@is.elta.co.il> References: <3B11464B DOT 31331 DOT D7FED AT localhost> (snowball3 AT bigfoot DOT com) X-mailer: Pegasus Mail for Win32 (v3.12c) Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > case _CS_PATH: BTW, one problem I just noticed in the Posix draft is that confstr() names the symbol '_CS_PATH', while in unistd.h it names the symbol '_CS_POSIX_PATH'. > > { > > char *djdir = getenv("DJDIR"); > > if (djdir) > > out_len = snprintf(buf, len, "%s/bin", djdir); > > I wonder: is this in the spirit of what Posix says? What if DJDIR is > changed during the program's run? Posix seems to indicate that > _CS_PATH should return the original value that is unaffected by > user-level changes. In the April 2001 draft, the standard wants whatever path is returned to point to the utilities: The confstr( ) function with a name argument of _CS_PATH returns a string that can be used as a PATH environment variable setting that will reference the standard shell and utilities as described in the Shell and Utilities volume of IEEE Std 1003.1-200x. But the draft does say its original use is much like the language you point out: The original need for this function was to provide a way of finding the configuration-defined default value for the environment variable PATH. Since PATH can be modified by the user to include directories that could contain utilities replacing the standard utilities in the Shell and Utilities volume of IEEE Std 1003.1-200x, applications need a way to determine the system- supplied PATH environment variable value that contains the correct search path for the standard utilities. > So perhaps we need something in the startup code which will stash away > the value of DJDIR as seen by the startup code. I'm tempted to say this is overkill because DJDIR isn't supposed to be changed by the user. But just because folks shouldn't doesn't mean they won't. > Btw, shouldn't we introduce into the system headers some new > preprocessing symbols which distinguish between the old Posix standard > and the new one? The new Posix specifies some additional preprocessing symbols: _POSIX2_VERSION by unistd.h and _POSIX_C_SOURCE presumably by 'gcc --posix'. BTW, the April 2001 draft can be downloaded from: http://anubis.dkuug.dk/JTC1/SC22/open/n3232/ Mark