Re: [pcre-dev] issue with pcre 7.8 in PHP lib

Top Page
Delete this message
Author: steve lu
Date:  
To: pcre-dev
Subject: Re: [pcre-dev] issue with pcre 7.8 in PHP lib
I am running PHP 5.2.9 with pre-packaged PCRE installation.

I ran "configure" to build PHP which results in a Makefile,
within the Makefile, I noticed that it uses a compiler define
"-DEBCDIC=0" to
compile pcrelib, which led to a wrong char table used in the build.

Steve



Gwynne Raskind wrote:
> On Aug 10, 2009, at 10:56 AM, steve lu wrote:
>> Hi,
>>
>> Soon after I posted this email, I found the cause.
>>
>> PHP 5.2.9's Makefile script has this compiler define, -DEBCDIC=0.
>> But in PCRE source, it uses '#ifdef EBCDIC #else #endif' to
>> conditionally include
>> a character table.
>>
>> This inconsistency led to EBCDIC always defined and thereby a wrong
>> character table used in the final build.
>>
>> Philip Hazel wrote:
>>>> When I execute this code below on MacOSX, php returns 1.
>>>>
>>>> print( preg_match('/[\d]/', '1') );
>>>>
>>>> but on Windows, it always return 0.
>>>>
>>> I strongly suspect this has nothing to do with PCRE, but everything to
>>> do with the way it is called from PHP. I'm afraid I can't help, as I
>>> don't know anything about PHP. (Or about MacOSX or Windows.) Have you
>>> tested other backslashed constructs? If this were a C program, you
>>> would
>>> need to use \\ in order to pass a single backslash to PCRE. Is it
>>> something like that?
>
>
> Can you be more specific about which PHP you're seeing this problem
> with? None of our released versions should be doing this by default.
> In fact, I don't think we ever do it at all.
>
> Off the top of my head I'd guess you're running into a problem with a
> distribution-specific version, but I also don't believe that even
> Apple's insane hacks (rant snipped) would have this specific effect.
>
> -- Gwynne
>
>