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