Regression with locales when using SQLSRV

[mpociot]

PHP version

8.4.3 / 8.3.17

PHP SQLSRV or PDO_SQLSRV version

5.12.0

Problem description

When the sqlsrv or pdo_sqlsrv extension is installed, there is a strange regression error when using certain locale specific PHP functions.

Expected behavior and actual behavior

Create a new file called test.php with the following content:

<?php

echo str_word_count('мама', 0, null);

The expected output of this is 0.
When the SQLSRV extension is enabled, this code returns 4.

Disabling the extension lets the code return 0 again.

[DanielRuf]

I've tried to reproduce it (on Windows and Linux).

OS: Windows
PHP 8.3.20
sqlsrv 5.12.0

Result: 0

OS: Linux
PHP 8.3.21
sqlsrv 5.12.0

Result: 0

[DanielRuf]

Hm, I can not even reproduce it on PHP 8.3.17 with sqlsrv 5.12.0. Am I missing a crucial step?

[ibakirov]

@mpociot Same expected output 0 on Windows and Linux

[jasonvarga]

Hi @DanielRuf I have created a repo with a test matrix that includes ubuntu and mac os.

https://github.com/jasonvarga/msphpsql-issue

Here's the workflow that shows the behavior: https://github.com/jasonvarga/msphpsql-issue/actions/runs/16836141618

There is a PHPUnit test that outputs LC_ALL and whether sqlsrv is enabled.

You can see that the mac os job with sqlsrv enabled fails.

The actual value of the str_word_count is debatable/irrelevant, the point is that it becomes inconsistent when you have sqlsrv enabled.

I hope this helps, and thanks!

[DanielRuf]

Not much progress with this.
Anyways, thank you for providing the reproducible example setup.

See beyondcode/herd-community#1282 (comment) for more details.

If this is a regression, which exact setups did still work?
Because version 5.12.0 of SQLSRV exists since April 2024.

So either something in the PHP packaging process has changed or in MacOS, which could lead to this.

If you find a state where it worked, and the earliest state where it failed, that would make things simpler (for example to bisect the exact cause or change which introduced this changed behavior).

[ibakirov]

@jasonvarga @DanielRuf Please take a look at PR #1069 which has been present in for a long time and tip for setting pdo_sqlsrv.set_locale_info = 0 and https://learn.microsoft.com/en-us/sql/connect/php/non-system-locale-settings?view=sql-server-ver17

[DanielRuf]

Interesting, so this is not new and not really a regression then.

Upon further checking, echo "$LC_ALL" on MacOS returns en_US.UTF-8, on Ubuntu it is not set.
https://github.com/DanielRuf/msphpsql-issue/actions/runs/16867790479/job/47777102177

Maybe it is a change introduced by newer MacOS versions?
So in this case the link to the documentation regarding locale settings is probably the right approach.

[DanielRuf]

My tests assume, that it is solely a MacOS issue with cyrillic / multibyte and the relevant PHP function(s).
At least without any MSSQL extension loaded the issue persists in MacOS:

https://github.com/DanielRuf/msphpsql-issue/pull/1

https://github.com/DanielRuf/msphpsql-issue/commit/e1aaec77a5e5318f62c830e47643fb699b8ce72e
https://github.com/DanielRuf/msphpsql-issue/actions/runs/17699005313/job/50302163798#step:6:36

https://github.com/DanielRuf/msphpsql-issue/actions/runs/17699113884/job/50302399201
https://github.com/DanielRuf/msphpsql-issue/actions/runs/17699176189/job/50302537973

I suggest opening an issue with the PHP core developers to check this in detail.
Which I did now for you at php/php-src#19828.
There you can also see, that the problem appears in macos 15+ but not in macos 14.

Please add any further details there. For now I would assume this is not a bug caused by the SQLSRV extensions and therefore would close the issue.