Re: [PHP-DEV] Support for Async / Await

Hi! > Does this actually fit in with php's execution model of each request > being a separate thread / process? As far as I understand this kind of > async programming is only useful within an event-loop architecture as > used by nodejs for example. There are things that do this for php like We

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

Hi! > You're right that turning off eval() isn't a silver bullet, and if you can > get external code running on someone's box there are a lot worse things you > can do. I think the important point here is not that you can do worse things than eval() but that you can do *anything*. Once you can

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

Hi! > Let's just say that eval() and create_function() are the cornerstone of > PHP-based exploit toolkits. Yes, if the hackers get in there are other > problems with your codebase, but as a defense in depth measure most > applications need neither create_function() nor the eval() language >

Re: [PHP-DEV] Warning for "confusable" types

Hi! > I was about to give my +1 on the more generic approach, but type hints > could also be interfaces and "instance of the class X" is not a good fit. We could use "class or interface" if that's important. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development

Re: [PHP-DEV] FFI & Security

Hi! > Recently we voted on classification criteria for security bugs [1], we > include under "not an issue" any issue that "requires invocation of > specific code, which may be valid but is obviously malicious". > > I would like to add an explicit clause under the "not an issue" section for >

Re: [PHP-DEV] Warning for "confusable" types

Hi! > Something I've seen play out a couple of times: Newbies try to use > something like "integer" or "resource" as a type, and then get a confusing > error message along the lines of "must be an instance of resource, resource > given". Maybe we should just change the error message to this?

Re: [PHP-DEV] exit() via exception

Hi! > For me, one of the most annoying things about this is that we can't perform > proper leak checks on code using PhpUnit, because it will always exit() at > the end, which will result in "expected" memory leaks. Is that something that might be fixed in phpunit? I am not familiar with this

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

Hi! > it into some kind of proxy war. Yes, "it breaks backwards compatibility for > questionable benefit" is an argument against this proposal, it is even a > *very good* argument against it, but it's also no mandate to shut down the > discussion entirely. Well, anyone is free to continue the

Re: [PHP-DEV] Internals "camps"

Hi! > Maybe that would be a way to move forward with some of the log jams here? I'm not sure where's the log jam here? An RFC proposing largely pointless deprecation not being met with overall enthusiasm is not a "logjam". It's a logjam only if somehow we were to imagine more BC breaks, more

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

Hi! > If you feel you want all those functions deprecated in favor of any other, > put up a RFC whenever you want to(No one is stopping you from that). That's part of the problem. RFC should be for something that is necessary and beneficial for the whole community, doubly and triply so when

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

Hi! > I was going to learn c++, but then I came across these weird operators >>> and <<. At first I thought they were heredoc, but, that obviously > wasn't the case. My next guess is that they were some sort of strict > comparison === is more strict than ==, so I figured >> is more strict > than

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

Hi! > PHP to new generations. It IS confusing if PHP has more than one way to do > one thing, and if one of them is considered better than the other nowadays, No it's not. At least no more than anything else in life. There's always alternatives to do something. And PHP has always been a language

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

Hi! > When evaluating the _unique_ cost of migrating legacy code, it should be > balanced with the _continual_ cost of keeping the feature. That includes: > > * People wondering what that strange syntax does, or, worse, mistaking it > with a variation of string literal. > * Difficulty to

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

Hi! > That is the purpose of the eventual vote, is it not? To allow the > community to make that determination. Not exactly - there should be a good reason before the RFC comes to a vote. If you're not sure there's a VERY good reason, there shouldn't be the RFC about it at all, at least not in

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

Hi! > We seem to be experiencing something of a philosophical clash with regard > to deprecation. Perhaps we should attempt to establish some general > guidelines for deprecation as a group? I personally thought we had thom - no removing things unless there's a very good reason to. And yet, we

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

Hi! > This is true, if you know they are called a backtick. It's not a I think it's reasonable to expect some minimal level of knowledge from the user. We're not targeting infants in the kindergarten here. So while we aim to not present too many obstacles to the novice user, we can reasonably

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

Hi! > Like I said, I can see arguments both ways, but use as a command substitution > operator is hardly a universal thing. Nobody said it's "universal thing". Virtually nothing is "universal thing" among over 9000 programming languages that exist. I just claimed it's a common thing which

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

Hi! > https://wiki.php.net/rfc/deprecate-backtick-operator-v2 Reading the justifications, I must say I do not find them very convincing. Specifically: > * Alternative functions exist which are more descriptive, easily understood, and more readily searchable (for example, many common Google

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > Although I agree with the action of removing those people, there were > no clear rules, or people who could 'officially' tell those people > "your behaviour is being disruptive". This RFC at least provides a > framework for that. We don't need any people that need to "officially" tell

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > I strongly disagree. > > Theoretically, if someone wants to send 'adversarial' communications > to other internals contributors, they should either do it where > everyone can see those messages, or not send them. I appreciate that this may be your personal preference, but it's just that -

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > You're right that 7.4 will probably come out, I remain concerned that > fixing any bugs that are found during the release process, or > inevitably those found after the 7.4.0 release occurs, would be more > difficult if people are hesitant to discuss issues on internals. What is the base

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > Another thing I feel I have to emphasize here. This has absolutely > nothing to do with successful 7.4 release. If from now on internals Unless I am missing something and we do have still unresolved issues that block the release? Then we probably should go back to figuring them out and not

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > This is a stop-gap measure to allow us to use the internals newsgroup > to be able to ship PHP 7.4 successfully. Another thing I feel I have to emphasize here. This has absolutely nothing to do with successful 7.4 release. If from now on internals became so bad we could literally agree on

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > Please can you look at the past 3 months of discussions on this list > and ask yourself have those conversations been productive and/or > pleasant? Do you think other people think those conversations have > been productive and/or pleasant? I've seen a lot of conversations here, both

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > taken part of). So given that track record, along with how the project > philosophy generally is, I do not see abuse being a problem, even the > sligtest. There are a lot of things that I thought our project philosophy does not admit, but turns out I have been wrong. I don't see why if we

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > Here is an RFC to "Prevent disruptions of conversations" > https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit I am not sure what is the purpose of this. Teaching other adults how to behave? Its usually a futile task. The RFC is expressed in extremely vague terms, like:

Re: [PHP-DEV] Defining the PHP Group

Hi! > For there to be a veto, of the kind that anyone can actually use, it must > be established somewhere. And that's what I am concerned about. Once we start assuming the RFC process is not for solving technical questions for everything, we get into this kind of rule lawyering and nitpicking

Re: [PHP-DEV] Defining the PHP Group

Hi! > Because it's a waste of everyone's time. The RFC process is the only one > we have. So? There was time where we had none. Processes are not some precious jewels that we occasionally happen to find by chance but can't have any more. We can create them. > To clarify, I wasn't trying to

Re: [PHP-DEV] Defining the PHP Group

Hi! > I'd like it if we could stop saying the RFC process can't be used for one > thing or another, it's patently false. Not can't, shouldn't be. And I don't see any reason why we should stop saying that. > To say it's not suitable for these things is a total nonsense, we already > use it for

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

Hi! > May I suggest to provide instructions to build using Docker? This has a > number of advantages: > > * Same instructions will work on Linux, MacOS and Windows > * No need to install build dependencies on your host > * Spin up a MySQL container by running 'docker run mysql:version' This is

Re: [PHP-DEV] Defining the PHP Group

Hi! > Then we should undo all changes (as far as possible) caused by the RFCs > listed in the Process and Policy section[1], probably starting with the > Voting (aka. RFC) process RFC itself, which by the way, states as > introduction since its very first version from 2011 (emphasis mine): > > |

Re: [PHP-DEV] Defining the PHP Group

Hi! > Does anyone object to any of those words ? Yes. I do not think precommitting to implement anything that has been put on wiki and passed the vote is a good thing. Its a good conflict resolution mechanism when we're talking about where or not to implement certain technical feature. But IMO

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! > FTR this is basically what Python does via defaultdict: > https://docs.python.org/3/library/collections.html#collections.defaultdict > > I think it is the "cleanest" solution to this problem overall. Though it > does need a separate structure, rather than our favorite PHP array. This is

[PHP-DEV] Re: non-PIC build broken on oss-fuzz

Hi! On 9/9/19 2:16 AM, Dmitry Stogov wrote: > I've just rechecked, when PHP configured with "--with-pic", libtool > generates only PIC object files and there is no difference between *.lo > to *.o files. Sorry, you were right, --with-pic works, it was my mistake. -- Stas Malyshev

Re: [PHP-DEV] FFI extension / NULL-Checks

Hi! > isset($err) > $err[0] != null > -> is always true, regardless of whether func as assigned an error or not > > $err[0]; > -> segfault This is a bit confusing - if $err[0] segfaults, how it can be != null? Does this behave differently in different contexts? Anyway, it shouldn't probably

[PHP-DEV] Re: non-PIC build broken on oss-fuzz

Hi! >> I added --with-pic, it didn't change anything, same error. > > See . I am sorry, I don't understand how that comment helps. Could you explain a bit further, what needs to be done to make the build work again? configure

[PHP-DEV] Re: non-PIC build broken on oss-fuzz

Hi! On 9/9/19 12:57 AM, Dmitry Stogov wrote: > how do you add "-pie" flag? I do not. I just compile PHP. The script used to configure and build it is here: https://github.com/google/oss-fuzz/blob/master/projects/php/build.sh There are no special flags there as far as I can see. The fuzzing SAPI

[PHP-DEV] Re: non-PIC build broken on oss-fuzz

Hi! > I suspect the problem caused by "-pie" linker flag (It requires all > object files to be build with -fPIE or -fPIC). > To quick fix this, you may add PHP configure flag "--with-pic". > Actually, this should build PHP as before the patch. I added --with-pic, it didn't change anything, same

[PHP-DEV] non-PIC build broken on oss-fuzz

Hi! Looks like commit eef85229d0fe9f69d325aa0231e592f35c468afb broke oss-fuzz builds: https://oss-fuzz-build-logs.storage.googleapis.com/log-66ab74a7-4ece-4e14-b21b-f60527dd7244.txt The error message is: Step #4: /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `php_stripslashes' with pointer equality

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! >> encountered a PHP developer who thought using uninitialized variables >> was fine. > > Now you have. Nice to meet you. And there are more of us. You learn something new every day! >> I knew it worked, but I always considered this to basically be >> the PHP equivalent of undefined

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! On 8/28/19 4:23 PM, Matthew Brown wrote: > $foo++ becoming 1 when $foo is undefined is not intuitive to me. I guess we have different intuition. > To take a very trivial example, that behaviour causes “for ($i = 0; > $i < 10; $I++) {}” to loop indefinitely. This is rather shallow issue,

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! > This is where I think PHP may have broken us a little. I think it's in no way "broken" to be able to easily match expectations, like $foo++ always do what you meant without clunky boilerplate. Also, if you think PHP is the only language I program in daily (and I mean every day, except some

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! > If we want PHP to be as easy as possible then $nullref->bar(), > $foo->someUndefined(), new UndefinedClass etc shouldn’t be exceptions > either - they can just be notices. I don't see how it follows. Calling unknown method does not have natural default - if I tell you "would you please do

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! > Because it's explicit, and incrementing null is mathematically > unintuitive. After all, null does not exist anywhere in the set of It is well-established in programming that default value for numeric types is 0 (many Java IDEs, for example, will explicitly tell you if you initialize a

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! > Javascript has treated undefined variables as a catchable exceptions since > (I think?) forever. Which seems to be why I open a random Javascript file in our codebase and see this: var wikibase = wikibase || {}; wikibase.queryService = wikibase.queryService || {};

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! > Besides, we have tools available for years now to make this behaviour > more defined: > > $counts[$key] = ($counts[$key] ?? 0) + 1; Sure, that works. But I don't see any way this clunker is better than $counts[$key]++ -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! > For example, I just recently fixed a bug, that did this: `$array['key'] += > $cost` - the array key was not initialised. Well, turned out that in this > case instead of null, it actually grabbed some garbage number out of memory This would be a serious engine bug that you should submit to

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! > Don't build your business on a foundation of eggshells and then complain > when something comes along that makes those eggshells crumble. I think PHP has historically been much less "bondage and discipline" language, strictly enforcing a particular programming paradigm, than others (e.g.

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hi! > But @$foo++ is just a really bad way of writing either $foo++ or $foo = 1. If you're working in an environment where you aren't sure if $foo has been mentioned already or not (ideally, you never have to, practically, you sometimes are) it's much easier to just do $foo++ than write code to

Re: [PHP-DEV] Remove special Zend karma

Hi! > Any objections to dropping this and have a single php-src karma for the > whole tree (with the exception of php_version.h, which is used to prevent > bad merges)? Makes sense to merge Zend karma into php-src karma (I imagine smaller karma sets, e.g. for tests or specific ext only,

Re: [PHP-DEV] PHP direction and governance [was: Re: [PHP-DEV] P++: FAQ]

Hi! > I disagree that (as I take away from your last sentence) the current > approach is better because it means people feel they have been properly > heard. I can think of recent messages on the list from people saying > that they don't feel heard. I'm not saying we have perfect record in

Re: [PHP-DEV] PHP direction and governance [was: Re: [PHP-DEV] P++: FAQ]

Hi! > I started for the same reason: to help the community pull together and > argue less, by having a codified set of values. The risk here however is for the document to be seen as a means to "argue less" by way of excluding certain points of view from discussion. That would not be a good

Re: [PHP-DEV] P++: FAQ

Hi! > Finally, Zeev, you mention the "PHP philosophy" of being a dynamic > language. While that may well be your philosophy, and you have every > right to have it, that has not been the "PHP philosophy" for years, > as seen by all of the type "stuff" that's been successfully added to > the

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Hi! > You and Zeev have disagreed with several RFCs that have passed, and > apparently you're perceiving that as "people committing changes > whenever they feel like". Please, for the love of all that is holy, do not try to guess what I think. You are bad at it. I never claimed that, never

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Hi! > This is why trying to force RFC authors to respond to every point is > such a bad idea. You try to absurdize the position by taking it to unreasonable absolute. Nobody asks anybody to respond to literally *every* point, no matter how minor. Responding on major objections, however, is

Re: [PHP-DEV] Merging fuzzing SAPI into core

Hi! > This is good for external (non-core and non-extension) collaborators, particularly allowing write access to those who wouldn't want or need write access to engine code. Yes, in theory. In practice I don't see too many of those flocking to it, unfortunately. As for process, I think we have

Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again

Hi! > I strongly doubt that there is anything that people could say that > would alleviate your concern. There's a lot of things people could say - for example, a proposal that does not have the same flaws. If you are fixed on having this proposal unmodified, then yes, my concerns are not

Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again

Hi! > If we want to evolve the language without breaking backwards compatibility, > we need to provide a way for gradual migration of the ecosystem: A library > should be able to opt-in to breaking changes, while remaining usable by > downstream consumers. Conversely, an application should be

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Hi! > You can either silently ignore somebody or announce it. You may > consider it a courtesy to have it announced so that they don't wonder > why they are not being replied to. For me it's perfectly fine. Sure I > wouldn't be happy if anyone said that about me, but I would have to > accept it.

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Hi! > I'm referring to the compiler and optimizer here. Especially in > namespaced code we pretty much always don't have a hard guarantee on > what function will get called. This means that we have to generate code > that dynamically dispatches between by-val passing and by-ref passing > (this is

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Hi! > Do your teams actively remove direct calls to array_push() and > array_multisort()? In any case, I’m sure that most PHP developers don’t. > > > Yes: usually replaced by `[]` or wrappers of those functions that > de-reference the variables, so that no references are used. Again,

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Hi! > This discussion seems to have lost track of the context ... the original > quote (which Stas cherry-picked in a way that lost the original meaning): > >> I think nowadays it is well known that by-reference passing is to be > avoided and I don't see it particularly commonly in user code.

[PHP-DEV] Merging fuzzing SAPI into core

Hi! As you probably know, we've been running PHP fuzzing under Google's OSS-Fuzz[1] project for a while now (and found and fixed some bugs due to it). This has been enabled by the PHP fuzzing API SAPI[2] which currently lives in a separate repository. Since the setup is working pretty well for a

Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again

Hi! >> I look at the success of how strict types was brought in, in a way > It was a classic compromise that neither side of the debate hated, > but neither really loved either, and the subtleties of how each mode > works are likely to be sources of confusion for years to come. I am > far from

Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax

Hi! > I do work with code like that: the teams maintaining these codebases are > actively removing by-ref calls when they encounter them.  You seem to be intent on equating your personal experience with needs of every PHP developer on the planet. I can't prevent that but I can say that this

Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again

Hi! > As we've seen with the declare for strict types, libraries that want > to have strict mode, and libraries that want to have more type > juggling, are perfectly fine to live alongside each other, and can be > used just fine. You are assuming all the code is neatly organized in "libraries"

Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax

Hi! > Nah, by-ref is pretty much avoided in OSS packages, but we can surely > survey the ecosystem to verify this. I literally work with code that uses references every day. So may be you haven't encountered it but the attitude of "nah, never happens" I think is a bit misplaced. Also please

Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again

Hi! > I plan to pick up this proposal again. I think the motivation here has > become more pressing in the meantime. The strict_operators proposal is > under discussion, and Rowan's "locked classes" essentially concluded with > "doing this with a declare is better". I also think that this

Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax

Hi! >> In short, while currently we have >> >> function byRef(&$ref) {...} >> byRef($var); >> >> this proposal would also allow >> >> function byRef(&$ref) {...} >> byRef(&$var); I am not sure why it is necessary. If you call a function, one would assume you know what it is

Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax

Hi! > I think nowadays it is well known that by-reference passing is to be > avoided and I don't see it particularly commonly in user code. By-reference I don't think it's true. It depends on the style of coding, of course, but there are many situations where the most convenient solution is

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

Hi! > V2 remedies that by maintaining default INI behaviour, as well as > nullifying the possibility of code / data leaks by throwing a compiler > exception if opportunity to execute a file which contains potentially leaky code. Oh, I thought it was already agreed upon... I thought the RFC

Re: [PHP-DEV] Stop replacing dots with underscores in query, post andcookie parameters for PHP 8?

Hi! > My preferred solution would be to add a new built-in function that > re-does the mangling exactly as it used to be done. It would be no great > maintenance burden on us to maintain such a function for the future, but > it would avoids userland having to reimplement it multiple times and >

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

Hi! > Would you (George, Nikita) consider removing the details about the eventual > removal of the feature from this RFC? We can run with the error for a > bunch of releases / years, and see what happens. I don't see why we should > necessarily decide now on something that might be 5 years or

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

Hi! > I agree. I don't think there's a pressing need to do the "full removal" in > PHP 8.1 in particular, so it makes more sense to this in the next major > version (9.0), as usual. This may be more acceptable, if we are sure there would be no short tags code remaining anywhere by the time of

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

Hi! > I did not want to just merge the original (accepted!) implementation > after the controversial discussion it triggered, but after reading this, > I realize that I just wasted my time here. So much for being nice and > giving people a fair change to reevaluate the proposal in light of the >

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

Hi! > That's precisely what this RFC is intended to prevent. This RFC does nothing to eliminate code written for short-tags - it is impossible to eliminate with any RFC, in fact, it is impossible to eliminate at all. So the only question is what is happening when server is encountering such

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

Hi! > Due to the controversy after the initial vote on the Deprecate PHP's Short > Open Tag RFC [1] here is a new RFC to deprecate them written with the help > of Nikita Popov . Could you please explain what has changed since the last time we discussed it that makes it necessary to bring the

Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations

Hi! > The reality is that right now, the PHP project somehow became > deprecation-oriented, and lost its long established guideline of bias for > downwards compatibility. Hear, hear! I am positively astonished at so many RFCs trying to deprecate so many functions in PHP. Who does it help? Who

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

Hi! > the quick fix descriptions of bugs.php.net[1] need some update. To my > knowledge, these come from the database, so could anybody with access to > it please take a look? Ideally, I think this should be in PHP file and not database, so it will be modifyable by project members without

Re: [PHP-DEV] Memory leak in eval()'d code

Hi! > I still don't understand *why*, then, the memory stays flat when the new > class does not happen in eval(): Because that code creates only one class. > I checked get_class() for all instances returned, **it's always the same > class name whether it's called from eval() or not**, so this

Re: [PHP-DEV] Memory leak in eval()'d code

On 6/28/19 3:37 PM, Benjamin Morel wrote: > That's not a "leak". You create new objects (in this case, classes), > they take memory. > > > Why do they not "leak" memory without eval() then? Replace with `$object > = new class {};` and memory usage stays flat. > There has do be some

Re: [PHP-DEV] Memory leak in eval()'d code

Hi! > I case this is non-trivial to fix. Each invocation recompile a new > piece of code, which creates a new class. That's not a "leak". You create new objects (in this case, classes), they take memory. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] [RFC] Deprecations for 7.4 - specifics

Hi! enable_dl - I am not clear what is proposed - to remove dl() functionality in PHP 8 completely, even in CLI? Or to keep it in CLI always on and remove the directive? My opinion: drop the directive, let the SAPI decide if dl() is possible, with CLI keeping it. Not sure about embed though. But

Re: [PHP-DEV] [RFC] Deprecations for 7.4

Hi! > In general, something is considered a primary vote if it could be > conducted independently of other primary votes in the same RFC - ie, it > is not an implementation detail. > > So, what we have here is multiple primary votes ... I am not talking bureaucracy here, I'm talking about

Re: [PHP-DEV] [RFC] Deprecations for 7.4

Hi! > While I understand where you are coming from on this, I do think that > functionality that is better supported by dedicated extensions to do > the job instead of providing some functions in the standard library > that converts from a few specific encodings to another: It may be supported

Re: [PHP-DEV] [RFC] Deprecations for 7.4

Hi! > I've update the RFC to say that the option will be removed without > deprecation, with argv always available on CLI and never on non-CLI. > Throwing a deprecation warning when accessing $argv in non-CLI SAPIs is too > complicated and/or unreliable. So this means CGI binary would not have

Re: [PHP-DEV] [RFC] Deprecations for 7.4

Hi! > Nikita and I would like to open the discussion for the RFC: > "Deprecations for 7.4", this RFC targets a larger set of various > features targeting for deprecation in 7.4 with the intention of > removal in PHP 8.0. My first question for many of those is - why? I.e. it deprecates a bunch of

Re: [PHP-DEV] PHP on OSS-fuzz

Hi! > Where are issues detected by oss-fuzz reported? Right now on https://oss-fuzz.com/testcases and I copy it to bugs.php.net. It should also send the email when one comes up, but I am not sure whether it goes to security@ too. Also the issues are on

Re: [PHP-DEV] PHP Docker images

Hi! > I'm aware there are php images available on Docker hub, but as their docs > state those are not to be confused with any official php image provided by > php upstream. Generally, nothing prevents anybody from building a set of docker images the second after PHP tag is released. The only

Re: [PHP-DEV] open_basedir?

Hi! > If scenario (a) gives even a slight security advantage over scenario (b), > we should think very carefully before removing the feature. There's definitely _some_ security advantage, defense is always in layers, and while open_basedir can not be made secure, it certainly can avert _some_

Re: [PHP-DEV] open_basedir?

Hi! > b) update the security policy (https://wiki.php.net/security) to state that > open_basedir bypasses are not security issues. I believe this has been part > of Debian's security policy for some time already. I think we've been treating them this way effectively for a while now. The big

Re: [PHP-DEV] Error instead of returning false

Hi! > My idea, extremely summarized, would be to take the functions that > return false/null when they 'error', and instead make them actually > throw an error. First of all, they definitely should not throw Error, because Errors are for very specific types of things that mean the engine does

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

Hi! > Every app will have different things to fix. So saying that this > particular change will break the internet is not realistic without any > numbers. If PHP is on a course to fix the BC break strategy then good I am not saying it will break the internet. Nobody does. What I am saying it

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

Hi! > Worth noting another inconsistency here that we've missed. PHP 7.4 has > introduced many BC breaks actually already. Without this level of > problems: Exactly, without. There's a difference between removing an unmaintained extension which is barely used and setting people up for displaying

Re: [PHP-DEV] [RFC] Allow throwing exceptions from __toString()

Hi! > Please could someone anyone who understands the implications for what > this means for the internals of the PHP engine provide some detailed > reasons for why this shouldn't be approved, if there are any reasons. > > Otherwise voters might 'irresponsibly' vote yes, without being aware of

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

Hi! > Why the hell should I start compromising with someone who thinks the > project, and by > extensions the contributors to the project small or large, don't behave > responsibly?! Without getting into generalities about all contributors over all the project lifetime, I personally think what

[PHP-DEV] Issuing CVEs for PHP

Hi! I have set up PHP as CNA (CVE Identifiers authority) with MITRE. That means that we will be assigning our own CVEs from now on. The process in broad strokes works like this: 1. We request a block of numbers 2. When we have security bug, we use one of the numbers in the block 3. We create CVE

Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

Hi! > Nikita, impressive leg work; thanks. It validates Bob's intuition from the > RFC ("... these occurrences are quite rare as it almost always is an error > in the current form, rendering the impact minimal.") If the impact is minimal, why do it at all? So, at the cost of BC break and

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

Hi! On 4/28/19 4:52 AM, Benjamin Morel wrote: >> I don't even mind still having a compile error in PHP 8 when it sees the > token I thought one of the arguments for the whole enterprise was to enable http://www.php.net/unsub.php

Re: [PHP-DEV] Revive Number Format Separator RFC

Hi! > A cursory scan of current usage suggests that number format separator might > be used in scenarios such as: > > Phone numbers > 919_555_1234 > 49_89_636_48018 Just noting here that using integers as phone numbers is not something we want to support, enable or promote. > Date time values

<    1   2   3   4   5   6   7   8   9   10   >