Re: Missing warning for stat(), etc. when invoked with empty string

On Thu, Dec 3, 2020 at 10:06 PM Levi Morrison via internals < internals@lists.php.net> wrote: > On Thu, Dec 3, 2020 at 6:30 AM Claude Pache <claude.pache@gmail.com> > wrote: > > > > [Of course, I meant stat(), not > > stats(). Resending the message with > correct spelling, including in subject line. Sorry.] > > > > > > Hi, > > > > stat() and friends invoked with empty string or null as > > argument, > return false (indicating failure), but do not emit the Warning > that is > expected on failure. See: https://3v4l.org/jXC2N > <https://3v4l.org/jXC2N> > > > > That discrepancy between the two ways of indicating failure is > problematic. Indeed, whenever I use one of those functions without > prefixing it by @, I expect that it will either return a value of expected > type (array in case of stat()), > or run the panic procedure of my error > handler. > > > > I propose to ensure that those functions always emit a Warning in each > and every situation they return false/null (provided, of course, that those > functions are not supposed to return false/null in absence of > failure, > and that their purpose is not to check for failure condition as in > file_exists()). > > > > —Claude > > > > This is a long-standing behavior. Further, I don't know many people > who want _more_ warnings in their codebase. > > In other words, I disagree with this proposal. This seems like a pretty odd position to take. I think there's two ways it can reasonably behave: 1. Always generate a warning if stat() fails. 2. Never generate a warning if stat() fails. While the current option is: 3. Always generate a warning if stat() fails ... unless an empty string was passed. I'm okay with either 1. or 2., but I don't think that 3. constitutes sensible behavior. Regards, Nikita