Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116641
MIME-Version: 1.0
Date: Mon, 13 Dec 2021 13:57:38 +0100
Message-ID: <CAJmy8YETz8t7JM5fpeAMUYOvU_apE8yscUxY2A6dPX4itVKOPA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000036c8ba05d306a005"
Subject: LOCK_SH for file_get_contents ?
From: divinity76@gmail.com (Hans Henrik Bergan)

--00000000000036c8ba05d306a005
Content-Type: text/plain; charset="UTF-8"

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

--00000000000036c8ba05d306a005--