Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44966
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain gravitonic.com from 209.85.210.196 cause and error)
MIME-Version: 1.0
In-Reply-To: <4A5CF17B.1040102@keryx.se>
References: <4A5CF17B.1040102@keryx.se>
Date: Tue, 14 Jul 2009 15:06:50 -0700
Message-ID: <7d6e34d80907141506m5ff583b4vb4e8da7cd969120f@mail.gmail.com>
To: Keryx Web <webmaster@keryx.se>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016361648b3d64f46046eb1a735
Subject: Re: [PHP-DEV] ctype functions going, going, gone?
From: andrei@gravitonic.com (Andrei Zmievski)

--0016361648b3d64f46046eb1a735
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On Tue, Jul 14, 2009 at 1:58 PM, Keryx Web <webmaster@keryx.se> wrote:

> Hi all!
>
> I am preparing a Server Side Scripting (using PHP) course for the Web
> Standards Project Interact[1]. As I am going through security considerations
> I note that the ctype functions are being used in the manual[2] and have not
> been deprecated in 5.3. I have, however, been told that they are not, nor
> ever will be, Unicode compatible.[3]
>
> If that indeed is the case:
>
> A. Should they not be deprecated formally, including giving an appropriate
> error when used? (Yes, that will give some people, like me, lots of errors.
> But I rather take them now than have my code blow up on me in the future.)
>
> B. Should not the the manual be telling people about these functions being
> non-future proof?
>

I believe the latest discussion settled on rewriting ctype_* functions to
use ICU internally in HEAD, so that they work correctly on Unicode strings.

-Andrei

--0016361648b3d64f46046eb1a735--