# LOCK_SH for file_get_contents ? - Thread: https://externals.io/message/116641 - Original archive: https://news-web.php.net/php.internals/116641 - Started by Hans Henrik Bergan on 2021-12-13T12:57:38+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 --- ## #116641 — Hans Henrik Bergan — 2021-12-13T12:57:38+00:00 URL: https://externals.io/message/116641#116641 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 --- ## #117576 — Hans Henrik Bergan — 2022-04-23T08:25:44+00:00 URL: https://externals.io/message/116641#117576 · In reply to: #116641 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 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 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 --- ## #117598 — Guilliam Xavier — 2022-04-25T13:01:35+00:00 URL: https://externals.io/message/116641#117598 · In reply to: #117576 First, hello... > This has been requested for years (since at least 2009?) but it seems no > > […] > 1), > > […] > controversial, > > […] > > 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. 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