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 <divinit...@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 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 >
