Hi!
> [http://archive.is/1A8SQ], wherein she suggested that you ignore the
And this is exactly what we want to prevent from happening here.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
> It might leave others feeling pressured, but it's not their fault if
> those contributors feel unsafe without a code of conduct. Nor is the
I don't want to be dismissive, but I do not see anything on the list
that should make anybody feel *unsafe* (unless of course I misunderstand
what you
Hi!
> Here's an RFC that would extend the syntax of list() to be more useful
> with associative arrays:
>
> https://wiki.php.net/rfc/list_keys
>
> Please read it and tell me your thoughts.
After reading the RFC, it looks like a great idea. I wouldn't exactly
encourage this for replacement of
Hi!
> That's a nice try, but since the Contributor Covenant is a political
> document, the politics of those who favor it are fair game. Also,
I don't think we need to discuss politics here, at least "politics of
those", i.e. personal views rather than merits of specific proposals. I
see no
Hi!
> Fedora detected a BC break in 5.6.18RC1 and 7.0.3RC1 related to
> session management.
Looks like something to do with last session changes. Yasuo, could you
take a look at it?
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi!
> We have 2 choices
> - Enforce new and correct behavior since it will not affect normal
>operation. i.e. Actual production site
> - Restore old behavior for the time being. (For this option, I prefer
>to restore only for PHP 5.6, but Ok for PHP 7.0 also. No for master)
Since it
Hi!
> In order to make suggestions to the wording of the RFCs, and included
> Contributer Covenant and Guideslines easier, I've imported it into
> GitHub:
>
> https://github.com/derickr/php-code-of-conduct/blob/master/RFC.rst
Great idea. Unfortunately, I don't see any way in Github to comment
Hi!
> You can't do it on the /blob/ view, but if you click on the commit to
> get to the /commit/ view, you can comment on that. :)
Right. That's what I meant by "patches". But that only specific commit,
not the whole result, right?
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP
Hi!
> I've decided to re-propose the CoC RFC. There are many reasons for it,
> but there are a few points I want to make.
>
> I strongly believe that a Code of Conduct is required. The amount of
> toxic behaviour on this list is in my opinion unacceptable. It drives
> people away, it
Hi!
> First, on process.
Tangentially related, by pure coincidence I was given today a link to an
IETF RFC describing their view on consensus:
https://tools.ietf.org/html/rfc7282
While their procedures are substantially different from ours, and for a
good reason, I think learning from their
Hi!
> Came to think on license keys for games. They always have a separator
> (using -) to increase readability. Which leads me to thinking, could the
> proposed number separator be used in cryptographic keys and is there
> a value in that?
Probably not. Crypto keys are usually pretty long
Hi!
> However there are lots of issues open from 'a while ago' that are
> either not really bug requests, or are too old to investigate.
Bug db also has feature requests. Which are fine, even if nobody does
them now, people may do in the future.
> I don't think having them kept open is
Hi!
> For old bug reports it might be reasonable to change the status to
> "Feedback" and ask, whether the issue still persists. This way the
> report is likely going to end up with "No feedback", what's IMHO better
> than "Closed" for such cases.
This is a good option too.
--
Stas Malyshev
Hi!
> Read failure is special because old save handler allowed returning false
> for read and continued as if there is no errors. I cannot fix this without
> braking buggy save handlers compatibility.
Ah, you mean when read actually worked but handler returns false? If the
session is set up
Hi!
> However, previous my fix (Raise warning and return false) was wrong fix.
> Therefore, I would like to correct (Provide new session ID and continue)
> it in 5.5 also. Does this make sense?
Yes, but nit sure if it's for 5.5. It's for Julian to decide,
ultimately, but it doesn't look like 5.5
Hi!
> I made PR
> https://github.com/php/php-src/pull/1721
>
> for bug #71038
> https://bugs.php.net/bug.php?id=71038
>
> Currently, the patch is written as it should and
> breaks compatibility on PHP 5.6.
>
> To be compatible with PHP 5.6 (PHP 7.0 is OK),
> it may ignore read failures
Hi!
> Yes we can!
>
> Let's say *we* would improve our conduct. I mean *we* as literally you
> and me: two individuals. As a result the conduct of "whole of internals
> as a group" would improve a bit. If improving our own individual conduct
Not by definition given by John - he said that
Hi!
> Right now I can call out your last paragraph. But before I do, remember
> John's point about perception versus reality. I go further. With respect
> to what goes down on a list-serv, there is only perception and nothing
> else matters. The following characterizations may seem wrong to you
Hi!
> Nice! I'll say one thing though: If we're going to introduce a class,
> I'm tempted to leave token_get_all alone (or at least limit its
> changes to what's in the current porposal), and have the PhpToken
> class implement its own static method to do the same thing. This
I like this idea
Hi!
> Let me reiterate that the question that was posed, and which I am
> answering is, “Why do people avoid internals?” and “Does internals
> want to attract newcomers?”
Sure, but you talked about specific behavior in specific discussion.
Except of an incident of some unfortunate name-calling,
Hi!
> I've disallowed empty session ID, but it wasn't a
> appropriate fix.
>
> https://bugs.php.net/bug.php?id=68063
Could you explain a bit more about the part where there are empty IDs
generated? You say it "is browser's cookie handling" - could you explain
more about it?
> I made
Hi!
> The root cause is browser's cookie handling.
> It appears that browsers do not lock cookie while updating cookies.
> Therefore race condition happens and browsers send empty cookie
> sometimes. I haven't checked the code, but observed it happens.
>
> I observed handful empty cookies a day
Hi!
> I have one idea. I made an awful mistake while drafting the Voting
> RFC, requiring a 2/3 majority for language changes. It should have
> been 85-90%. When you have a 85-90% majority - it's likely to imply
> several things:
I have a feeling that wouldn't help. Instead of "it's toxic
Hi!
> I don't think that's a fair characterization of this discussion. Some
> people have questioned what this is a solution to, but most haven't.
> Some have questioned if we have a problem, but most haven't.
Again, "a problem". You and Pierre are talking as if there's specific
problem you have
Hi!
> Even without that, though, it's clear we *do* have more serious issues
> than just "rudeness". When a major contributor is getting death-threats
> over an RFC, *there is a problem*. That they're happening off-list
> doesn't change the fact that *that is a problem*.
OK, so to evaluate
Hi!
> This is yet another example of the toxic internals problem.
> Regardless of one's views on the CoC proposal, the conduct of
> php-internals as a whole has been reprehensible.
What in your opinion was reprehensive, could you explain?
> And *every* time I start to think, "ok, I'm finally
Hi!
> This particular case isn't what a CoC would protect. So I think that's
> a bit of a red herring. The CoC doesn't try to enforce itself outside
> of the scope of project members. Instead, it applies to project
OK, that is clear enough, but I see an issue here - we'd be applying an
pressure
Hi!
> the anonymous voting was reverted almost instantly, or about the recent CoC
> discussion which was back and forth between having the voters/reporters
> privacy, shielding them from potential backlash or having more transparency
> for the voting results, so I'm curious about what Stas meant
Hi!
> least hold ourselves to a level of mutual respect. Going out and
> calling someone a moron in public is not constructive nor respectful,
> and IMHO we as a project shouldn't sit back and blindly say "whatever"
> if it happens.
OK, so what should we do instead? So far my calls to apply some
Hi!
> I fail to understand how one can think that the CoC could be about
> censorship (which is basically what this comment says).
I can explain you that very easily: there are known instances where CoCs
were used and even more instances where there were attempts to use CoCs
and CoC-like
Hi!
>> A suggestion from a co-worker who's worried about seeing patterns like:
>>
>> case ($t['token']) {
>> case T_PAAMAYIM_NEKUDOTAYIM:
>> // do something
>>break;
>> case ord(';'):
>> // do something else
>> break;
>> }
What's wrong with this pattern? Looks pretty fine to
Hi!
> Perhaps then show them once the vote is closed?
That's possible.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
> This seems useful. I do wonder whether we should use by default for
> RFCs. It's interesting to see how different people vote, and knowing who
I think we talked about it, and decided not to do it. Anything changed?
> One concern I have with the patch is that it doesn't appear (by my
>
Hi!
> I was not hesitant (or, let's maybe call it "intentionally
> procrastinating") to post on this topic because I felt unsafe on this
> list or in the general realm of the PHP community; I simply was in no
> mood to deal with a mob of self-proclaimed-or-not "Social Justice
> Warriors" and
Hi!
>>> Perhaps then show them once the vote is closed?
>>
>> That's possible.
>
> I do not see how it helps except to... know who voted what. Indeed if
> we only show who voted but not how, that's fine. If not, it makes the
> whole thing useless.
The idea is that while vote is open, only
Hi!
> Aside from Phil Sturgeon (who used unacceptably harsh language), the
> people who support this have been exceedingly reasonable. We've been
I could bring some choice quotes (not only from Phil) which nobody would
call reasonable, but that's not the point. I don't want to have a
contest of
Hi!
> $counts[$item] ?? $counts[$item] = 1 ?? $counts[$item]++;
This looks completely unreadable and I do not think it works:
https://3v4l.org/PlAHH
Seems to leave $counts as 1 always. But even if it didn't, I would never
pass that on code review - it is very hard to understand what's going on
Hi!
> For those still in doubts, ask users why they don't post to the list.
> Why they don't contribute. Our reputation of agressivity (and I take the
> blame on that too) did not do us any good and still do not.
I think we have here very basic difference in definition. Being
aggressive and
Hi!
> No. I will be willing to cut scope overall to cut how much it tackles
> in the first swing, but I strongly believe that there needs to be some
> sort of non-public resolution process defined.
I agree, non-public CRT as part of the proposal seems fine. The punitive
action is a bit more
Hi!
> when doing something defined as invalid will be hard. If you don't want
> to count garbage, then you should use if()
>
> if (!is_garbage($key)) @$count[$key]++;
And if you want to check, just do:
if (is_garbage($key)) { throw Exception("Garbage!"); }
Except in this case you know what's
Hi!
> I am referring to multiple comments here of actual harassment or bad
> behavior (I described what it is) and agressivity.
I still do not have any example of "actual harassment" that happened
anywhere on community resources. Even examples of bad behavior that got
people banned weren't
Hi!
> This is exactly what slightly annoys me to be honest. It exactly why
> we need a private group to deal with such events, even rare, or even
> if they will never ever happen again.
>
> Despite numerous people saying that it happens, including me. You
> still say, heh, that's some vague
Hi!
> One problem we discuss this using two different ends. I mainly focus on
> providing tools to ensure we have a safe context. While you seem to
> ensure that we do not mistakes, do not ban innocent or apply censorship
> inadvertently.
If you looks at creating safe context without worrying
Hi!
> What I said is that these are two different points and should be
> discussed separately. Yes, it will be part of the RFc but talking many
> points at the same time is impossible.
No, I don't think it's two different points, at least as far as punitive
functions go. If we omit the punitive
Hi!
Since in CoC discussion it was mentioned we may need anonymous voting,
I've created a patch that allows anonymous polls to be created:
https://github.com/php/web-wiki/pull/7
The results still recorded per user, but everybody can see just their
own vote (for logged in users) and total
Hi!
> I think many do agree. If you look at this 225+ reply thread, the vast
> majority of karma holding people have not responded (even many who
> frequent this list). A few (5+) of them have reached out to me
> personally to say that they are explicitly staying out of this
> discussion because
Hi!
> And then Phil Sturgeon else used a sexualized term to insult Paul to his
> ~16k followers but didn't name him: https://archive.is/oeekT
I think that is a clear example of something that would be prohibited by
CoC. We do not need to split hairs here about what each exact word
means, it is
Hi!
> It is not what I am referring to but harassment, insults, attacks or
> similar events. I do not think we need to discuss endlessly that we
Proposed CoC says "insulting/derogatory comments" and "[o]ther unethical
or unprofessional conduct". And that can be (and in some cases has been)
Hi!
> A code of conduct without an enforcement mechanism is useless. It's very
> nice to be able to say that we don't condone harassment or abuse, or
> that personal attacks or publishing personal information are not
> acceptable, but if we can't enforce it, then it falls down the moment
But we
Hi!
> And yes, I am aware that a large part of the concern is the definition
> of "malicious jackass who hurts people" and "hostile, insulting storm".
Not only that. But that even if we have the definition, nobody walks
around with a convenient label of "malicious jackass who hurts people"
on
Hi!
> You're missing the basic point. If someone makes a complaint with a
> complaints process that handles everything in the open, i.e. with your
> suggestion of the standard RFC process:
What you say is true. However, as I previously said, the alternative is
taking action on behalf of the
Hi!
> This was tried once [1] and there was an immediate knee-jerk reaction [1]
> which resulted in quickly removing the feature. Maybe the winds have
> changed between then and now?
That was for technical RFCs, for which I still thing it is wrong. But,
for conflict resolution, it may be
Hi!
> What it means is the other person can open their PHP-DEV email folder
> and know that there's not going to be any subtle crap from the person
> that is harassing waiting for them when they want to contribute to
> PHP.
I though we were discussing applying CoC *outside* php lists. PHP-DEV
Hi!
> It is broad for a reason. If harassment that's obviously connected
> with the project (it would need to be obviously connected) happens
> off-list, that's still problematic. I think limiting the scope to just
> the project territories is dangerous as it provides too easy of a way
> for
Hi!
> I'm glad you brought this back up, but you seem to have remembered a
> few things incorrectly.
And this is a good example why information from both sides is essential.
Everybody has their own story, and human memory is unbelievably faulty
even with the best of intentions. When some
Hi!
> Also, I think it's worth bearing in mind that unintentional offence
> which is not persistent is unlikely to fall under this rule. Consider
> that this is roughly the standard that actual law follows, e.g. Section
> 4A of the Public Order Act 1986 in the UK:
>
>> (1) A person is guilty of
Hi!
> There is the risk with public votes that whoever votes a particular way
> gets harassed for the way they voted. While this doesn't happen very
> much in technical discussions, I think there's a greater risk of that in
> a vote on whether to sanction a person for unacceptable behaviour.
Hi!
> Interface is a good way to implement new functionality for classes, but
> operator overloading is language feature itself, so from my point of view,
> it will be better to put this functionality into the magic method.
No contradiction here. Language features can use interfaces, see
Hi!
> How exactly would you feel about having all of this made explicit to all
> the other PHP devs? Presumably you look up to some of these people -
I presume you would feel bad. However your example is purely theoretical
and hand-crafted to exactly fit your argument. It is easy to imagine
Hi!
> That is the problem: you cannot discuss how to protect the accused
> without having the context of the abused. As you have yourself pointed
> out with examples, it is a tradeoff.
But that is exactly what I want - to have full(er) context! The secret
procedure makes that harder. Of course,
Hi!
> It's interesting to note how few people in this thread consider the
> perspective of potential harassed or abused people - instead only
> focusing on how to protect the accused.
We do not discuss it much because it is a) covered in the RFC thus
forming context of the discussion and b) most
Hi!
> Yes, I thought it up, hence it's theoretical. If you think that means it
> hasn't happened countless times along those lines, you need to learn how
> to google.
I hope you realize how weak is an argument along the lines of "I am
right, if you don't see it, learn how to google".
> Is there
Hi!
> In response to significant feedback here and elsewhere, I have
> expanded the text of the RFC significantly. It now includes the text
> of the Contributor Covenant 1.3.0 as well as including verbage about
> updating it requiring an RFC.
Thanks for improving the RFC. It is already much
Hi!
>> True, but as Larry said, either side is problematic. Too loose of a
>> CoC with no enforcement and nothing really was changed from today
>> considering we already have the post that Rasmus made 6-7 years ago.
That implies we do *need* change from situation today. But so far I
didn't see
Hi!
>> True, but as Larry said, either side is problematic. Too loose of a
>> CoC with no enforcement and nothing really was changed from today
>> considering we already have the post that Rasmus made 6-7 years ago.
That implies we do *need* change from situation today. But so far I
didn't see
Hi!
> Exhibit A:
> https://github.com/CoralineAda/contributor_covenant/commit/0e927bc01614d6b0de021a314dbe95e7dfcc7bb9#diff-eacf331f0ffc35d4b482f1d15a887d3bL17
>
> Exhibit B: https://archive.is/dgilk (the threatening language at the
> end is particularly chilling)
>
I think this kind of
Hi!
> Warn at 2 weeks, close at 4? There's no real harm in closing it unmerged:
> the submitter can always resubmit.
That sounds way too short. I mean if we did process all worthy pulls in
matter of days, then fine (but see below) but we are very far from that.
And when we take a long time to
Hi!
> I have created a new RFC for the PHP Project to adopt the Contributor
> Covenant as the official Code of Conduct for the project
>
> https://wiki.php.net/rfc/adopt-code-of-conduct
>
> Let me know what you think or if there are any concerns
Looks to me like solution in search of a
Hi!
> constraint on function parameters and return types. I think it would be
> more worth pursuing a Haskell-style approach in PHP, most likely with a
> hierarchy of magic interfaces.
I agree that interface approach looks better than Python/C++ approach
for PHP. One thing it also allows is
Hi!
> https://wiki.php.net/rfc/token-get-always-tokens
>
> This should be pretty non-controversial. I hope?
No way!
Just kidding :) I think it's a great idea, token_get_all() is annoying
to deal with. We'd have to fix token_name though so that this would
still work:
foreach ($tokens as
Hi!
>> We could, of course, do something like
>> $token[0]<=255?$token[0]:token_name($token[0]) - but that looks hacky.
>>
> Do you mean have users of the API do that? Or have the implementation
> of token_name() do that? Because the latter doesn't seem unreasonable
> at all.
I meant for
Hi!
> for that to happen you need a corrupt CoC team, a fairly unknown N
Define "corrupt". They may believe they are doing the world a huge favor
by getting us rid of horrible, terrible, no good N. The problem is that
they'd be doing it without needing any consensus and will have a good
chance
Hi!
> Right, that's one of the parts that need more work and thoughts. My
> comment was mainly about the usefulness of a CoC.
If we're talking about having a declaration of principles, I am not sure
we need elaborate text to say "don't be an ass" but I don't mind having
one in case somebody ever
Hi!
> The effort to create and adopt a CoC is minimal and the benefits are
> huge. It creates, confirms or ensure that the context of the php.net
> remains a safe for anyone to contribute.
It also provides a way for 5 (or, since CoC mechanisms are not specified
at all, even 3 assuming CoC
Hi!
> be rarely needed, I could only remember/find two instances when we had
> to ban somebody from the list:
> http://marc.info/?l=php-general=102852881828032=2 (which was a
> controversial action as it turned out later)
> and
> https://www.mail-archive.com/internals@lists.php.net/msg57482.html
Hi!
> It's really not much more than Wheaton's Law in a form that
> (hopefully) is just detailed enough to stop someone from being able to
> say "but you didn't explicitly say I couldn't abuse someone because
> $X".
That assumes we told somebody that anything goes unless it's explicitly
Hi!
> currently I (and a bunch of other people) could revoke anybody's karma,
> how is this any different(ofc. it would be reverted and I would get a
> scolding)?
The difference is that those 5(3) people get a special stand, while
right now everybody is equal (well, there are RMs but that is
Hi!
> 2) To the claim that "we're all equal now", that's hogwash. :-) PHP
> Internals may not have a formal structure or hierarchy beyond Release
> Managers, but because it's a group of more than 2 people there is of
> course an implicit, informal power structure. The best writeup on that
>
Hi!
> difficult as it would be unlikely that 5 people would all be 'corrupt' in
> the same fashion compared to one where lots of individuals hold that power
> and can exercise it on their own.
Here's that "corrupt" again - but the point here is that no corruption
is necessary. Human perception
Hi!
> Patricio Tarantino has asked me to help him propose Operator
> Overloading in PHP 7.1 (based in part on my operator extension in
> PECL). I think we can expose this to usespace as magic methods with
> very little overhead (the runtime check and dispatch is already there,
> after all).
We
Hi!
> Hilarious to hear you cite that as the already existing inconsistency
> between += and ++ with non-numeric strings came up only last week.
>
> $x = 'foo';
> $x++; // $x === 'fop'
> $x += 1; // $x === 1
Exactly, because on strings ++ and += 1 are not the same operator. And,
as you noted,
Hi!
> Ringing in the new year with a proposal to retool name mangling:
While the variable name changing probably outlived its usefulness with
the demise of register_globals, changing it would produce serious BC
issues with which we should be very careful. Emitting E_DEPRECATED based
on user data
Hi!
> I am looking to submit an RFC in order to remove the error suppression
> operator in PHP, namely the @ symbol.
I don't think it is a good idea, currently, for the following reasons:
1. A lot of functions produce error messages which may not be important
in specific scenario, and the users
Hi!
> // With the new array syntax this has been improved to
>
> list ($a, $b) = [1, 2];
>
> // I think this new syntax should logically extend to
>
> [$a, $b] = [1, 2];
list() and array() are two different language constructs, using the same
syntax for them is a bad idea.
--
Stas
Hi!
> I would like to restart better session management for PHP 7.1.
>
> https://wiki.php.net/rfc/precise_session_management
I've read the RFC and I have some questions and comments:
1. I do not see why old session being active is a problem when you
regenerate. You write "Attacker may abuse
Hi!
> Why not use RC2 as a chance for some security patches to get tested ?
> If we have a RC2 (which is not bad IMO, we have a time slice here at
> end of 2015 that enables us to release an RC2) , we then could merge
> into this one some well-selected security patches, f.e, some
Hi!
> That means 5.6 EOL is 20 months and 11 days away. That's more than one
> and a half years, it should be enough time to upgrade.
I'm not sure what you mean here by "should be". If you mean "if
everybody dropped everything right now and started only working on
upgrade to PHP 7 then they
Hi!
> Giving everyone until the end of 2017 to update their servers is more
> than sufficient.
Sufficient for what? It is a hard fact that people still run 5.3
version. In fact, 2/3 of sites run EOLed versions. You can always say
they have only themselves to blame, but then I'm not sure what
Hi!
> If 2/3 of sites still run EOLed versions of PHP, all adding a long-term
> support version is going to do is encourage habits of inertia. "Well,
You seem to be under impression that we have some control over these
habits. We do not. There are a lot of factors that influence these
decisions,
Hi!
> IMHO, I think we need to look at the 5.6 lifecycle very differently from
> how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
> the last version that's relatively completely painless to upgrade to from
> 5.x (especially 5.3 and later).
We could make 5.6 an LTS
Hi!
> It has been brought to my attention that my consistent use of \ prefixing
> of global functions is an eyesore, but I've got a simple little PoC that
> shows why I do it, and now I'm wondering if the behavior I'm working around
> should qualify as a PHP bug?
No, it's not a bug, it is a
Hi!
> Never mind. It returned. Congratulations everyone!
Congratulations to us all and many thanks to those who worked tirelessly
to make it happen and produce the best PHP version yet!
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi!
>> Well said. But why, then, do we provide Windows binaries?
Windows as a platform is different from Linux/Mac in several aspects: in
how easy it is to obtain binary (without php.net ones), how easy it is
to build one and how easy it is to an average user of the platform to do
that
Hi!
> To fix the HashDos vulnerability for *all* cases (rather than just GET/POST
> parsing), I propose to introduce collision counting during hashtable
> insertion operations. This will throw a fatal error if the number of
> collisions during an insertion operation exceed a certain threshold.
>
Hi!
> It may not be documented, but that doesn't put it outside the scope of
> BC. People will unintentionally rely on bugs.
People might, but we are under no obligation to keep bugs around for
these people.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development
Hi!
> It can't wait for 7.0.1, because banning this would be a
> backwards-compatibility break with 7.0.0. We have to fix it in 7.0.0 or
> not fix it ever.
In theory, yes. In practice, if somebody starts using 7.0.0 and
immediately jumps to using \int, I don't feel too bad for breaking that
Hi!
>> > function a(\int $i) {}
>>
>> Is it intentional that the \ in front of the "int" is allowed? IMHO,
>> this
>> confusing notation must not be allowed.
>
> This is weird and I'd consider it a bug. You can't do \array or
> \callable, and if I saw \int, I'd think it meant a
Hi!
> So in the end, a solution is wanted. I don't think any opinion is
> allowed to be ignored for such a topic. So options
>
> a) release on 26th including all known bug fixes
> b) do RC8, assume there are no bugs, so target 10th for RTM
> c) do RC8, release on 3rd, expect there are no bugs
Hi!
> I’m requesting that the functions taint() and untaint() as well as
> the ability to log taint information be available in the standard
> interpreter without extensions.
Given that this feature has performance implications, and not
universally needed, I don't think this would be a good
Hi!
> As discussion seems to have died out, I would like to propose moving
> to the next stage for inclusion of taint as a first class feature of
> php 7.1.
What is the difference between what exists now (i.e., extension) and
what you seek to do in 7.1? What do you mean by "first class feature"?
801 - 900 of 3108 matches
Mail list logo
