Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112403
Return-Path: <cschneid@cschneid.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 19680 invoked from network); 4 Dec 2020 07:44:28 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 4 Dec 2020 07:44:28 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 5230B1804DD
	for <internals@lists.php.net>; Thu,  3 Dec 2020 23:12:35 -0800 (PST)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2
X-Spam-Virus: No
X-Envelope-From: <cschneid@cschneid.com>
Received: from darkcity.gna.ch (darkcity.gna.ch [195.49.47.11])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Thu,  3 Dec 2020 23:12:34 -0800 (PST)
Received: from dynamic.wline.6rd.res.cust.swisscom.ch (unknown [IPv6:2a02:1205:5053:a220:a4ef:2ebf:8f53:6f3b])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by darkcity.gna.ch (Postfix) with ESMTPSA id 1D4F36C160B;
	Fri,  4 Dec 2020 08:12:32 +0100 (CET)
Message-ID: <3BF9A0D0-95EB-4ED5-AF97-63665D6CE81F@cschneid.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6D12E49E-3782-4584-A7ED-B6B6B0672506"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 4 Dec 2020 08:12:31 +0100
In-Reply-To: <CAF+90c_zQ=fs-XUFJ0DikrG4tsLpTngxRm9oLBdLnJkHpAg5Sg@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
To: Nikita Popov <nikita.ppv@gmail.com>
References: <34FA3E20-9D06-4D08-937E-4216FEF35504@gmail.com>
 <7E98C687-7A24-49E7-A14C-3D68B4B3419E@gmail.com>
 <CAAKU0ukpCZvQfgxXJjupOifHcAtkq5Kq_8Sd7JF2so6xykD03A@mail.gmail.com>
 <CAF+90c_zQ=fs-XUFJ0DikrG4tsLpTngxRm9oLBdLnJkHpAg5Sg@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Subject: Re: [PHP-DEV] Missing warning for stat(), etc. when invoked with
 empty string
From: cschneid@cschneid.com (Christian Schneider)

--Apple-Mail=_6D12E49E-3782-4584-A7ED-B6B6B0672506
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Am 03.12.2020 um 22:13 schrieb Nikita Popov <nikita.ppv@gmail.com>:
> On Thu, Dec 3, 2020 at 10:06 PM Levi Morrison via internals <
> internals@lists.php.net <mailto:internals@lists.php.net>> wrote:
>> This is a long-standing behavior. Further, I don't know many people
>> who want _more_ warnings in their codebase.
>>=20
>> In other words, I disagree with this proposal.
>=20
>=20
> This seems like a pretty odd position to take. I think there's two =
ways it
> can reasonably behave:
>=20
> 1. Always generate a warning if stat() fails.
> 2. Never generate a warning if stat() fails.
>=20
> While the current option is:
>=20
> 3. Always generate a warning if stat() fails ... unless an empty =
string was
> passed.
>=20
> I'm okay with either 1. or 2., but I don't think that 3. constitutes
> sensible behavior.


Wel,, there is actually a third case: null (which is also the reason for =
the empty string behavior)

Some people might use it like "I have a filename but there is no such =
file, so stat() should issue a warning because something unexpected =
happened" and "I have no filename so the warning is not necessary".

So 3 might not be completely useless. That being said: I'm not against =
changing 3 to 1, I just wanted to point out the null-case.

- Chris


--Apple-Mail=_6D12E49E-3782-4584-A7ED-B6B6B0672506--