Bug #77937 [ReO]: preg_match failed

From: Date: Thu, 25 Apr 2019 10:03:39 +0000
Subject: Bug #77937 [ReO]: preg_match failed
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-220608@lists.php.net to get a copy of this message 
Edit report at https://bugs.php.net/bug.php?id=77937&edit=1

 ID:                 77937
 Updated by:         requinix@php.net
 Reported by:        v-altruo at microsoft dot com
 Summary:            preg_match failed
 Status:             Re-Opened
 Type:               Bug
 Package:            PCRE related
 Operating System:   Windows 10
 PHP Version:        7.3.5RC1
 Assigned To:        cmb
 Block user comment: N
 Private report:     N

 New Comment:

Hmm, yes, it seems Windows will quite happily accept any "language" or
"language_country" string regardless of whether either part exists, as long as the
language code is 2 or 3 characters.

var_dump(setlocale(LC_ALL, "xjq_ASDF")); // returns xjq_ASDF
var_dump(setlocale(LC_ALL, "0")); // still xjq_ASDF

FFS.

So for maximum portability it seems you have to list Windows-specific strings before the normal
strings. Or at least the codes it accepts before any short ones.

setlocale(LC_ALL,
  "Portuguese_Portugal.28591", // windows okay (28591 is the codepage for ISO 8859-1),
linux ignored
  "Portuguese_Portugal",       // windows okay, linux ignored
  "Portuguese",                // windows okay, linux ignored
  "pt_PT.ISO8859-1",           // windows ignored (bad codepage), linux okay
  "pt_PT",                     // windows okay (wrong), linux okay
  "pt"                         // windows okay (wrong), linux okay
);


Previous Comments:
------------------------------------------------------------------------
[2019-04-25 09:14:28] cmb@php.net

Thanks for reporting!  I can reproduce the *test* *failure*. The
problem is that setlocale()[1] claims to support "pt_PT", but
actually it does not.  Actually supported locales would be "pt-PT"
and "portuguese".

I'm not sure yet what to do about this.  Simply fixing the test
case for Windows would be an option, but that would not fix the
underlying issue which may affect existing userland code.

[1] <https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=vs-2019>

------------------------------------------------------------------------
[2019-04-24 22:24:29] a at b dot c dot de

Incidentally, the test cited in the original report uses the string
"aàáçéè", not Hebrew characters.

------------------------------------------------------------------------
[2019-04-24 22:20:37] a at b dot c dot de

Adding the /u modifier to the pattern would help (assuming the source is encoded in UTF8 - you
can't even SAY "aאבחיט" in ISO8859-1).

------------------------------------------------------------------------
[2019-04-24 20:45:09] requinix@php.net

Last I knew Portuguese does not cover Hebrew characters.

------------------------------------------------------------------------
[2019-04-24 20:33:06] v-altruo at microsoft dot com

Description:
------------
Failed regardless of OPCache being enabled or disabled and if it was TS or NTS. 
Test file location: ext\pcre\tests\locales.phpt

Test script:
---------------
setlocale(LC_ALL, 'pt_PT', 'pt', 'pt_PT.ISO8859-1',
'portuguese');
var_dump(preg_match('/^\w{6}$/', 'aאבחיט'));


Expected result:
----------------
int(1)

Actual result:
--------------
int(0)


------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=77937&edit=1

Thread (9 messages)

« previous php.bugs (#220608) next »