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_PATHcurrently collides withLOCK_SH(they're both 1),
lets changeFILE_USE_INCLUDE_PATHto 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_PATHhere
(i thinkLOCK_EXcould 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_EXbut 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_PATHcurrently collides withLOCK_SH(they're both
1),
lets changeFILE_USE_INCLUDE_PATHto 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_PATHhere
(i thinkLOCK_EXcould 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_EXbut file_get_contents does not supportLOCK_SHcan we at least change
FILE_USE_INCLUDE_PATHto 8 / (1<<3) ? that would
allow a userland implementation of file_get_contents to supportLOCK_SHand
FILE_USE_INCLUDE_PATHThe current situation is so bad that
FILE_USE_INCLUDE_PATHliterally 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