This has been requested for years (since at least 2009?) but it seems no
actual plan has been proposed
How about this?
since we already have the constant FILE_USE_INCLUDE_PATH
, seems it was
introduced in PHP5.0.0,
1: FILE_USE_INCLUDE_PATH
currently collides with LOCK_SH
(they're both 1),
lets change FILE_USE_INCLUDE_PATH
to something that doesn't collide with
any of LOCK_SH
| LOCK_EX
| LOCK_NB
for example (1 << 3) / int(8)
2: change argument #2 from "bool $use_include_path = false" to "int|bool
$flags = 0" , treating bool(false) the same as int(0) and bool(true) the
same as FILE_USE_INCLUDE_PATH
, and support LOCK_SH
| LOCK_NB
|
FILE_USE_INCLUDE_PATH
here
(i think LOCK_EX
could also be supported, but that might be controversial,
and the use case is certainly limited, if there is one at all)
because it's kind of silly, and at times annoying, that file_put_contents
support LOCK_EX
but file_get_contents does not support LOCK_SH
can we at least change FILE_USE_INCLUDE_PATH
to 8 / (1<<3) ? that would
allow a userland implementation of file_get_contents to support LOCK_SH
and
FILE_USE_INCLUDE_PATH
The current situation is so bad that FILE_USE_INCLUDE_PATH
literally cannot
be used in strict_mode=1, it's pretty much completely useless since php
7.0, so I doubt it'll break anything keeping up with new releases of PHP.
On Mon, 13 Dec 2021 at 13:57, Hans Henrik Bergan divinity76@gmail.com
wrote:
This has been requested for years (since at least 2009?) but it seems no
actual plan has been proposed
How about this?
since we already have the constantFILE_USE_INCLUDE_PATH
, seems it was
introduced in PHP5.0.0,1:
FILE_USE_INCLUDE_PATH
currently collides withLOCK_SH
(they're both 1),
lets changeFILE_USE_INCLUDE_PATH
to something that doesn't collide with
any ofLOCK_SH
|LOCK_EX
|LOCK_NB
for example (1 << 3) / int(8)
2: change argument #2 from "bool $use_include_path = false" to "int|bool
$flags = 0" , treating bool(false) the same as int(0) and bool(true) the
same asFILE_USE_INCLUDE_PATH
, and supportLOCK_SH
|LOCK_NB
|
FILE_USE_INCLUDE_PATH
here
(i thinkLOCK_EX
could also be supported, but that might be controversial,
and the use case is certainly limited, if there is one at all)because it's kind of silly, and at times annoying, that file_put_contents
supportLOCK_EX
but file_get_contents does not support LOCK_SH
First, hello...
This has been requested for years (since at least 2009?) but it seems no
actual plan has been proposed
How about this?
since we already have the constantFILE_USE_INCLUDE_PATH
, seems it was
introduced in PHP5.0.0,1:
FILE_USE_INCLUDE_PATH
currently collides withLOCK_SH
(they're both
1),
lets changeFILE_USE_INCLUDE_PATH
to something that doesn't collide with
any ofLOCK_SH
|LOCK_EX
|LOCK_NB
for example (1 << 3) / int(8)
2: change argument #2 from "bool $use_include_path = false" to "int|bool
$flags = 0" , treating bool(false) the same as int(0) and bool(true) the
same asFILE_USE_INCLUDE_PATH
, and supportLOCK_SH
|LOCK_NB
|
FILE_USE_INCLUDE_PATH
here
(i thinkLOCK_EX
could also be supported, but that might be
controversial,
and the use case is certainly limited, if there is one at all)because it's kind of silly, and at times annoying, that file_put_contents
supportLOCK_EX
but file_get_contents does not supportLOCK_SH
can we at least change
FILE_USE_INCLUDE_PATH
to 8 / (1<<3) ? that would
allow a userland implementation of file_get_contents to supportLOCK_SH
and
FILE_USE_INCLUDE_PATH
The current situation is so bad that
FILE_USE_INCLUDE_PATH
literally cannot
be used in strict_mode=1, it's pretty much completely useless since php
7.0, so I doubt it'll break anything keeping up with new releases of PHP.
After some search, I assume you're referring to
https://bugs.php.net/bug.php?id=47115 (Request #47115 Can't use flag
LOCK_SH
in file_get_contents "similar to file_put_contents can use
LOCK_EX"). I'm more "empathetic" to that than with your mails alone.
Anyway, I doubt FILE_USE_INCLUDE_PATH
can be changed to 8, because that's
already FILE_APPEND
(and both can be used with file_put_contents()
). Here's
the current (PHP 8.1, unchanged since at least 5.6) var_export()
of
array_filter(get_defined_constants(), function ($k) { return preg_match('/^(FILE|LOCK)_/', $k); }, ARRAY_FILTER_USE_KEY)
:
array (
'LOCK_SH' => 1,
'LOCK_EX' => 2,
'LOCK_UN' => 3,
'LOCK_NB' => 4,
'FILE_USE_INCLUDE_PATH' => 1,
'FILE_IGNORE_NEW_LINES' => 2,
'FILE_SKIP_EMPTY_LINES' => 4,
'FILE_APPEND' => 8,
'FILE_NO_DEFAULT_CONTEXT' => 16,
'FILE_TEXT' => 0,
'FILE_BINARY' => 0,
)
(ignore the last two). Actually it almost looks like it's only "by chance"
that file_put_contents()
can use LOCK_EX
(2 i.e. 1<<1) together with
FILE_USE_INCLUDE_PATH
(1 i.e. 1<<0) and FILE_APPEND
(8 i.e. 1<<3)...
That said, [I don't think LOCK_SH
= 1 can be changed, but] maybe
FILE_USE_INCLUDE_PATH
can be changed to e.g. 32, along with your suggestion
2 (change argument #2 [of file_get_contents()
] from bool $use_include_path = false
to int|bool $flags = 0
[but] treating true
like
FILE_USE_INCLUDE_PATH
[rather than 1 i.e. LOCK_SH] [note sure about
LOCK_NB
though])?
(PS: there's also file(), which currently supports
FILE_USE_INCLUDE_PATH, FILE_IGNORE_NEW_LINES
and FILE_SKIP_EMPTY_LINES...)
Regards,
--
Guilliam Xavier