Resending this, because the mail daemon sent it back as spam, and we shouldn't be running our own mail server any more than we should have been running our own git server. Seriously. What about this looks spammy, I ask you?
On Wed, Jun 23, 2021 at 9:36 AM Sara Golemon <poll...@php.net> wrote: > On Mon, Jun 21, 2021 at 6:29 PM Craig Francis <cr...@craigfrancis.co.uk> > wrote: > > On Tue, 22 Jun 2021 at 12:18 am, Benjamin Morel < > benjamin.mo...@gmail.com> wrote: > > > On Tue, 22 Jun 2021 at 01:06, Derick Rethans <der...@php.net> wrote: > > >> On 21 June 2021 23:37:56 BST, Yasuo Ohgaki <yohg...@ohgaki.net> > wrote: > > >> > > > >> >The name "is_trusted" is misleading. > > >> >Literal is nothing but literal. > > >> > > >> I agree with this. The name is_trusted is going to be the same naming > > >> mistake as "safe mode" was. Developers will put their trust in it > that it > > >> is 100% guaranteed safe. > > > > > > > > > FWIW, agreed, too. Trusted is vague and may imply some false sense of > > > security. Literal is literally what it says on the tin. > > > > > > > Yasuo's contrived "faking it" eval example aside, I 100% agree with > Derick, Benjamin, Levi, > and everyone saying that `is_trusted` is quite possibly the worst name > that could be > chosen for this. ((Okay, they didn't say that, but I am)) > > Why not call it `is_safe` and really embrace the bad idea that was > safe_mode properly. > No. Nope. Hard no. > > > I can follow up properly tomorrow, but by popular request we do support > > integers as well (could be seen as stretching the definition of > “literal” a > > bit). > > > > Is a hard coded integer not a literal value? > Nothing about the name 'literal' speaks to type, only to provenance. > > > Then someone said they wanted to check if an integer was a literal too - > > but because of technical limitations, it now allows any integer, > > regardless of where it came from, to be treated as a literal. > > > > Oooooh, I missed this. Yeah. No. > If the provenance of an integer is unknown then it is neither literal nor > trusted. > It's a grenade and precisely the kind of thing that breaks any attempt at > safety. > Why can this not be tracked? Is there no space in the zval to track > IS_LITERAL > as a flag rather than (and I'm making guesses about the current > implementation here) > storing it off the zend_string? As a zval flag, it becomes theoretically > applicable > to any type (though for obvious reasons resources and objects have a hard > time > demonstrating literality). > > > That said, I’m really glad that the only issue we seem to have is the > name. > > > > As I've said off-list more than once, I'm not a fan of this feature in > general as > it provides a false sense of security, so no... the name is not the only > issue. > Using a loaded word like 'trusted' just makes the false-security > implication worse. > > Take all that as you will because I'm probably still -1 on the feature > overall > regardless of the name, so my opinion on the name probably doesn't matter > in that respect, but for me at least, it turns my probable -1 into a > definite -1. > > -Sara >
