DomainKey-Signature: a=rsa-sha1; c=nofws; d=SSpaeth.de; h=from:to:cc:subject
	:in-reply-to:references:date:message-id:mime-version:
	content-type; q=dns; s=sspaeth.de; b=IqEXMWc+vrQ7rebXJP1srrDE/TN
	es0SoX2x6owQt83pqXH2da6+FbL8JLaqtuWTkwhxHIHraDLTxECZrJ2FHuw5qfUL
	JFyXoKEX0m6AiYXUISe1iaWFklzL1dY2Th7RwcxEEt2qTvzaH/3KK5CN+Pq3Dd0e
	mVlX5X180O3QDI0g=
From: Sebastian Spaeth <Sebastian@SSpaeth.de>
To: Austin Clements <amdragon@mit.edu>, Martin Owens <doctormo@gmail.com>
Subject: Re: Unicode Paths
In-Reply-To:
 <CAH-f9WtL4Lwrf2qSzpgeLL5nA_2_mFxUm6cFLmfO9UK_aKmCkg@mail.gmail.com>
References: <1315972539.2201.11.camel@delen>
	<CAH-f9WtL4Lwrf2qSzpgeLL5nA_2_mFxUm6cFLmfO9UK_aKmCkg@mail.gmail.com>
User-Agent: Notmuch/0.7-19-gee4579a (http://notmuchmail.org) Emacs/23.2.1
	(x86_64-pc-linux-gnu)
Date: Fri, 16 Sep 2011 12:58:49 +0200
Message-ID: <8762ksbvo6.fsf@SSpaeth.de>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Cc: Notmuch developer list <notmuch@notmuchmail.org>
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Thu, 15 Sep 2011 13:52:12 -0400, Austin Clements <amdragon@mit.edu> wrot=
e:
> On Tue, Sep 13, 2011 at 11:55 PM, Martin Owens <doctormo@gmail.com> wrote:
> > Hello Again,
> >
> > I notice in the lib code notmuch_database_open(),
> > notmuch_database_create() these functions use const char *path for the
> > directory path input. Is this unicode safe?
> >
> > The python bindings (and ctype docs) seem to suggest using something
> > called 'wchar_t *' for accepting unicode but that's for C not C++.
> >
> > Is this something that should be patched?
>=20
> char* is the correct type for paths on POSIX systems.  The *meaning*
> of those bytes is a more complicated matter and depends on your locale
> settings.  On old systems it was generally ASCII, on modern systems
> it's generally UTF-8, and it can be many other things.  However, as a
> consequence of UNIX's C heritage, it is *always* terminated with a
> NULL byte and cannot contain embedded NULL's.

Right, that's what we are doing, passing in utf-8 encoded unicode
strings to char*, which should be just fine if that is what the
underlying OS uses.

> wchar_t is another matter entirely.  wchar_t is the type used by C to
> represent wide strings internally, which generally (but not
> necessarily!) means it stores a Unicode code point.  However, this
> isn't an encoding, and different compilers can give wchar_t different
> meanings, so wchar_t strings aren't generally appropriate for storing
> or sharing between processes or with the kernel.

Mmh, I remember I attempted to user wchar_t to pass in unicode objects
directly and it had failed miserably.

Sebastian

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5zK+kACgkQVYX1jMgnoGJF4ACeLfr8tALkONoR/7EP2MfaAOVE
vyYAni93lhVz+va98EK7K9z7I6DN0t9l
=5i5Y
-----END PGP SIGNATURE-----
--=-=-=--