# Fw:  Dummy calls for 5.3.0 up? [Was: HEAD tests broken under Windows]

- Thread: https://externals.io/message/38182
- Original archive: https://news-web.php.net/php.internals/38182
- Started by Steph Fox on 2008-06-12T09:53:06+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #38182 — Steph Fox — 2008-06-12T09:53:06+00:00

URL: https://externals.io/message/38182#38182

OK, I'm now seeing a pass rate that more or less matches the same tests run 
by the PHP 5 test script and PHP 5.3 binary.

 `FILE_BINARY` is needed in two of seven calls to `file_put_contents()`. Get it 
wrong (either way) and you get a random warning or notice. It's completely 
non-portable too - it will only be accepted under PHP 6.

There is far too much of this kind of thing. Can we please consider adding 
dummies into at least 5.3.0 and possibly even the 5_2 branch for:

is_binary()
is_unicode()
file_put_contents(FILE_BINARY)

and any other major 'gotchas' that people can think of that will make it 
impossible to write future-compatible PHP 5 code?

Thanks,

- Steph


----- Original Message ----- 
From: "Steph Fox" <steph@phparch.com>
To: "internals" <internals@lists.php.net>
Sent: Thursday, June 12, 2008 3:32 AM
Subject: [PHP-DEV] HEAD tests broken under Windows


>
>
> Hi all,
>
> I'm hopeful that run-tests.php will now work as advertised under CVS HEAD 
> in most places. However it's still not right under Windows, and I finally 
> tracked that down to the fact that `file_put_contents()` in PHP 6 will 
> insist on creating a file with DOS line endings. The test files are 
> created from .phpt --FILE-- sections using `file_put_contents()`, so there 
> are a vast number of fails under doze due to an extra character in output 
> strings there.
>
> There's a *closed* PHP bug on this which was raised by Zoe over a year 
> ago, see http://bugs.php.net/bug.php?id=41609. For some obscure reason it 
> was seen as a documentation problem at the time. This is an extreme change 
> in behaviour, not a documentation problem, and needs proper analysis.
>
> Could someone please look into it?
>
> Thanks,
>
> - Steph

---

## #38183 — johannes@schlueters.de — 2008-06-12T11:35:00+00:00

URL: https://externals.io/message/38182#38183 · In reply to: #38182

Hi,


> There is far too much of this kind of thing. Can we please consider adding 
> dummies into at least 5.3.0 and possibly even the 5_2 branch for:
> 
> is_binary()
> is_unicode()

These can be easily emulated using PHP like
  if (!function_exists("is_binary")) {
    function is_binary($s) { return is_string($s); }
  }

> file_put_contents(FILE_BINARY)

Would a const `FILE_BINARY` = 0; be enough or would that break the
function in some way (didn't check it)

> and any other major 'gotchas' that people can think of that will make it 
> impossible to write future-compatible PHP 5 code?

as long as such an emulation is possible I'd prefer putting them in a
compatibility layer (like PEAR PHP_Compat) using PHP instead of putting
"useless" (mind the quotes ...) functions into PHP.

Stuff like the b prefix or (binary) casts are different as they can't be
emulated using userland stuff.

johannes

> Thanks,
> 
> - Steph
> 
> 
> ----- Original Message ----- 
> From: "Steph Fox" <steph@phparch.com>
> To: "internals" <internals@lists.php.net>
> Sent: Thursday, June 12, 2008 3:32 AM
> Subject: [PHP-DEV] HEAD tests broken under Windows
> 
> 
> > […]

---

## #38184 — Steph Fox — 2008-06-12T11:54:01+00:00

URL: https://externals.io/message/38182#38184 · In reply to: #38183

Hi Johannes,

> These can be easily emulated using PHP like
>  if (!function_exists("is_binary")) {
>    function is_binary($s) { return is_string($s); }
>  }
>
> > […]

Obviously... I was just thinking about the amount of stuff that would need 
to be added to that compatibility layer, and how it might affect 
portability. Not everyone uses PEAR and here we're more or less forcing a 
dependency on it, with the option being to knit one's own. Also, since many 
are only now moving from PHP 4, it seems a bit harsh to tell them they're 
going to have to change their code all over again in a couple of years' time 
for PHP 6 when they could be doing it all at one hit.

> Would a const `FILE_BINARY` = 0; be enough or would that break the
> function in some way (didn't check it)

#define PHP_FILE_TEXT 32
#define PHP_FILE_BINARY 64

And again, yes you can do it in userland code (FILE_TEXT, FILE_BINARY) and 
it harms nothing.

> as long as such an emulation is possible I'd prefer putting them in a
> compatibility layer (like PEAR PHP_Compat) using PHP instead of putting
> "useless" (mind the quotes ...) functions into PHP.

We'll have to agree to disagree over this...

- Steph