Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030205164855.03326cf0@pop3.rowe-clan.net>
Date: Wed, 05 Feb 2003 17:59:23 -0600
To: Branko =?iso-8859-1?Q?=C4=8Cibej?= <brane@xbc.nu>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: Proposal: new filepath API for search paths
Cc: "William A. Rowe, Jr." <wrowe@rowe-clan.net>, dev@apr.apache.org
In-Reply-To: <3E41809A.9030506@xbc.nu>
References: <5.2.0.9.2.20030205141915.03326cf0@pop3.rowe-clan.net>
 <5.2.0.9.2.20030205141915.03326cf0@pop3.rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At 03:22 PM 2/5/2003, Branko =C4=8Cibej wrote:
>This is where it stops working. On Windows, at least on NT-class
>systems, you really do want to use the wide char functions to read the
>environment and convert the result to UTF-8, otherwise we're not safe in
>the presence of characters that can't be represented in the current
>locale. I don't want to lose that capability, after all the trouble we
>(you?) went to in the other I/O functions.

Look at what we are doing in apr_app_initialize ... actually yes - the
environment is utf8'ed from the 'pure' Unicode command line and
environment table.

However ... if you are using it as a library that doesn't build for APR,
you are right, we can't really do this.  I don't have any objection to
an apr_env_get/_set() api (especially since setenv doesn't exactly
do what users expect on win32.)

Let's tackle the one, then the apr_env api :-)

Bill