Edit report at https://bugs.php.net/bug.php?id=77937&edit=1
ID: 77937
Updated by: cmb@php.net
Reported by: v-altruo at microsoft dot com
Summary: preg_match failed
-Status: Re-Opened
+Status: Closed
Type: Bug
Package: *General Issues
Operating System: Windows 10
PHP Version: 7.3.5RC1
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of cmbecker69@gmx.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=f3ff72e54b2f6c2fa1ac924ad95455a5309099d5
Log: Fix #77937: preg_match failed
Previous Comments:
------------------------------------------------------------------------
[2019-06-06 08:28:57] cmb@php.net
Related To: Bug #78115
------------------------------------------------------------------------
[2019-05-16 09:11:11] cmb@php.net
The following pull request has been associated:
Patch Name: Fix #77937: preg_match failed
On GitHub: https://github.com/php/php-src/pull/4169
Patch: https://github.com/php/php-src/pull/4169.patch
------------------------------------------------------------------------
[2019-05-07 21:26:06] cmb@php.net
I've made a patch[1] which is supposed to be as backward
compatible as reasonably possible. To ease testing, respective
binary snapshots[2] are available as well. I hope to get some
feedback on that before proceeding.
Thanks!
[1] <https://github.com/cmb69/php-src/commit/fa35882831010861aea3c4b2d12dd4d3d0fb64a7>
[2] <https://windows.php.net/downloads/snaps/ostc/77937/>
------------------------------------------------------------------------
[2019-04-25 17:03:31] cmb@php.net
This issue is neither directly PCRE nor testing related. Consider
the following script:
<?php
var_dump(17.4);
var_dump(setlocale(LC_ALL, 'pt_PT'));
var_dump(17.5);
var_dump(ctype_alpha(224));
?>
This outputs on my Windows system:
float(17.4)
string(5) "pt_PT"
float(17,5)
bool(false)
The first three lines indicate that pt_PT is properly supported,
but the failing ctype_alpha() shows that it is not really.
The following C program confirms that the issue is not directly
related to PHP:
#include <stdio.h>
#include <ctype.h>
#include <locale.h>
int main()
{
struct lconv *lc1 = localeconv();
char *loc = setlocale(LC_ALL, "pt_PT");
struct lconv *lc2 = localeconv();
int alpha = isalpha(224);
printf("%s %s %s %d\n", lc1->decimal_point, loc, lc2->decimal_point, alpha);
return 0;
}
Outputs on my Windows system (when built with VC15):
. pt_PT , 0
Again, ctype fails to properly recognize the locale (which is the
reason for the failing test, since PCRE2 calls ctype functions to
build the character tables).
If I build with VC11, I get:
. (null) . 0
Apparently, AppVeyor behaves either like this, or it properly
recognizes pt_PT for the ctype functions.
------------------------------------------------------------------------
[2019-04-25 10:03:38] requinix@php.net
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
);
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=77937
--
Edit this bug report at https://bugs.php.net/bug.php?id=77937&edit=1