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

Hi! >> A friendly reminder that some people are hosting customer code which they >> do not want to touch but will get support requests once the code breaks. >> >> - Chris >> > > That's normal? Everyone has projects to maintain, and breaking changes are > common: they're gonna call you for one

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

Hi! > If this RFC has caused such a resonance _after_ the vote, maybe, it > can be reopened for a few days so that those who have not voted can > do it? These concerns were expressed before the vote too. They were thoroughly ignored. That didn't make them disappear. -- Stas Malyshev

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

Hi! > A 68% majority which barely clears the 2/3 requirements for something as > fundamental as that - with so many core devs against it - we'll deserve all > the criticism that will be coming our way in 7.4/8.0 from end users > wondering why we needlessly broke their apps and made migration a

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

Hi! > It'd be swell if PHP's ternary matched other languages, but it doesn't, and > we have 20 years of code in the wild which has accepted that fact and moved > on. I don't see the benefit in breaking that code. Advise the use of > parentheses and move on. Exactly. -- Stas Malyshev

Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers

Hi! > 2. Improve caller control on unserialization. Change the signature to > public Phar::getMetadata ( mixed $allowed_classes = true ) : mixed, and > invoke the behavior similar to how unserialize itself works. Since all > of this problem stems from the use of untrusted content on the phar:// >

Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers

Hi! > This issue was discussed in this list before. > As long as PHP calls unserialize for phar metadata, object injection is > possible > which may allow malicious code execution. Right. That's why I want to make it not unserialize this data unless it's explicitly being requested. > I'm not

Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers

Hi! > Thanks for responding to this issue. > > Will calling getMetaData still parse and  > execute malicious code? If it's contained in phar and serialized data and the surrounding code (I understand that most techniques mentioned in the article rely on certain vulnerable code being present)

Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers

Hi! > I came across this article which highlights a few issues with PHP > deserialization techniques: > > https://portswigger.net/daily-swig/phar-out-php-deserialization-techniques-offer-rich-pickings-for-security-researchers PHP serialization is not meant to be used with external or

Re: [PHP-DEV][DISCUSSION] Multilingual PHP

Hi! > I'll stop there cause I know there are problems I haven't thought of. And > I'm not going to argue the syntax I just kicked out from the top of my head > is the best either. For better or for worse, English is the lingua franca of the internet technology. You can, of course, create a

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

Hi! > Inspired by Bob's recent RFC for concat precedence, I'd like to propose a > deprecation and removal of the left-associative behavior of ternaries. > Instead, explicit parentheses should be used: > > https://wiki.php.net/rfc/ternary_associativity Please, let's not mess with language syntax

Re: [PHP-DEV] Parameter skipping

Hi! > The problem I see with this approach is that a keyword for skipping > parameters > would really just be a stopgap solution until something like Named > Parameters > can be added. > > Is it really appropriate to add a feature that only serves a temporary > purpose? That was an argument in

Re: [PHP-DEV] Updating bundled libs (specifially, oniguruma) on 7.1/7.2

Hi! > As we encourage system library usage (default in 7.4), and if this raise > the minimal allowed version, this will create issue for 7.4 We can do it in different way. Update the bundled versions, but not raise the requirements. I can make the code adapt to old versions (at the cost of

Re: [PHP-DEV] Updating bundled libs (specifially, oniguruma) on 7.1/7.2

Hi! > 7.1 have version 5.9.6 > 7.2 have version 6.3.0 > 7.3 have version 6.9.0 (latest is 6.9.1) > 7.4 only use system library > > As we encourage system library usage (default in 7.4), and if this raise > the minimal allowed version, this will create issue for 7.4 > > Ex > RHEL have 5.9

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

Hi! > I feel like concatenation having the same precedence than addition > and subtraction is promoting programmers to make mistakes. Albeit > typically easy to catch ones, it is a quality of life change at > least. Changing operator precedence is usually a very bad idea, because it tends to

Re: [PHP-DEV] Firebird - Who are WE ...

Hi! > News to me is > https://firebirdsql.org/en/news/revival-of-php-driver-development/, but > then many Firebird user groups do not have English as a first language > and just get on with things locally. Well, this sounds good, but are these people going to develop it outside PHP project? Or

[PHP-DEV] Updating bundled libs (specifially, oniguruma) on 7.1/7.2

Hi! I wonder if there's any reason not to update bundled oniguruma library for 7.1/7.2. 7.1 one is ancient, 7.2 one is more recent but still behind. There are numerous fixes, I am sure, and one functionality improvement that allows to implement proper stack depth limiting

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

Hi! > I see the following options to go about this extension: > > 1) Add a deprecation warning as the functionality will effective cease > to exist in php-src. We don't know if this extension will be taken As an end user (in this case, PHP developer that needs to use Firebase functionality), I

Re: [PHP-DEV] Firebird - Who are WE ...

Hi! > "we" are. Like are you kidding me, honestly. Can't you just say > whether it is "we" as in: > > - The Firebird community > - The Interbase community > - or a combination? > - Borland? > - Aston Tate? > - The dBase developers? Also, I wonder could someone from the "we" come forward and

Re: [PHP-DEV] RFC Draft: Comprehensions

Hi! > It's not that you can't make an array into a generator, but you can't make > an eagerly-evaluated expression into a lazily-evaluated one. Not sure what you mean here. If you already have the data, of course you can't un-evaluate it in order to lazily-evaluate it again. But why would you,

Re: [PHP-DEV] RFC Draft: Comprehensions

Hi! > Honestly, I cannot think of any case where I'd use a comprehension > where I would definitely want an array and not a generator. In the > majority case both work equally well, cool, but I don't know when I > would even use an array-dependent version. They wouldn't work equally well.

Re: [PHP-DEV] RFC Draft: Comprehensions

Hi! > In Python, the difference is that []-syntax gives you a list > (pre-comupted), whereas without the [] you get a generator > (generate-on-demand). This distinction is important because the > generator might be iterating over something non-repeatable (e.g. another > generator), or have some

Re: [PHP-DEV] PHP_VERSION_SERIES_EOL_DATE or similar constants?

Hi! > It would be really useful for e.g. code check systems, tools like > Composer, hosting platforms, to inform the user of an upcoming or past > EOM/EOL date, without having to maintain a list of these dates > separately (by copying from, or scraping, php.net/eol.php). Why not create a

[PHP-DEV] PHP on OSS-fuzz

Hi! Looking at the recent PHP security issues, it is clear that many of them are stemming from corner cases in various format-parsing code, and most of them either is or can be found by fuzzers. Thus, I've made an initial integration for PHP on OSS-fuzz project - a fuzzing engine for testing

Re: [PHP-DEV] RFC Draft: Comprehensions

Hi! > I think my main point of feedback would be to stick closer to existing PHP > syntax, even if it costs us some brevity. I would prefer > > $gen = [foreach ($list as $x) if ($x % 2) yield $x * 2]; > > over > > $gen = [for $list as $x if $x % 2 yield $x * 2]; Agree here. There's a

Re: [PHP-DEV] RFC: Locked Classes

Hi! > While it can be useful, the ability to set an object property which is > not part of the class definition can also lead to subtle bugs. Banning > this for all objects would be a significant and painful breaking change, > so I propose instead the option to mark a particular class with a new

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

Hi! > I'm currently going through the PHP doc to remove mentions of PHP 4 > and stumbled upon the short_open_tag ini directive [1] which only affects > the availability of ` From my understanding, the ` so maybe we should deprecate PHP's short tag altogether? Why? What would it improve for

[PHP-DEV] Re: Weird bitset shift offset in zend_alloc

Hi! > This is intended x86 specific optimization. The behavior of SHR is > documented. > > See https://c9x.me/x86/html/file_module_x86_id_285.html > > "The count is masked to 5 bits, which limits the count range to 0 to 31" > on 32-bit systems. I see. But I wonder whether the compiler will

Re: [PHP-DEV] Weird bitset shift offset in zend_alloc

Hi! > But I'm not sure how it's supposed to work. Is it correct that on GCC > (and clang, presumably, since it defines __GNUC__) accept long bitshifts > and do the right thing with argument like 138? Is it documented > anywhere? Or is there a bug here? > > > This is a bug, yes.

[PHP-DEV] Weird bitset shift offset in zend_alloc

Hi! I've been working on running PHP with undefined behavior sanitizer (http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html) and I've encountered a weird error while running PHP: /src/php-src/Zend/zend_alloc.c:585:9: runtime error: shift exponent 138 is too large for 64-bit type

Re: [PHP-DEV] print with newline

Hi! > No, wrong. This is Twitter. > > I made a reasonable proposal with possible solutions, examples and > references: It does not matter what you did before. It's not a "who spit on whom first" discussion in a kindergarten. It's "you don't use this kind of language here, period" discussion on

Re: [PHP-DEV] print with newline

Hi! > My apologies, I was obviously not being clear. What I should have said is > fuck yourself. Please avoid such language on the list. This is not Twitter and not any other forum where such things are welcome. If you can't keep yourself within the bounds of civilized discussion, you probably

Re: [PHP-DEV][RFC] Cast in foreach

Hi! > I'd like to propose opening an rfc to make the following syntax legal: > > foreach($array as (int) $i) {} > > Which would be functionally equivalent to > > foreach($array as $i) { > $i=(int) $i; > } This doesn't seem to add anything to existing functionality - what's wrong with just

Re: [PHP-DEV] Optional catch binding

Hi! > Allthough global exception catching might not be a good practice per se, I > don't see a real reason to forbid it. However, these are 2 independent > features that can be voted for I guess. It's not forbidden now. But there's no reason to encourage it and develop a dedicated syntax for it.

Re: [PHP-DEV] Mitigate “Magellan vulnerabilitites” in PHP 7.2?

Hi! > In my opinion, adding this ini setting to PHP-7.4 is a no brainer, but I > suggest that we backport it to PHP-7.2 as well. I don't see a reason why not - if the option is useful for improving security/stability, let's backport it. If it's security related, maybe even to 7.1 since it's

Re: [PHP-DEV] bugs.php.net problems?

Hi! > Are you still seeing this? It is a Digital Ocean VM in NYC1 and I don't > see anything odd aboout it. Are you hitting it over ipv4 or ipv6? Seems to be ok now. Given that TLS handshake always worked fine, I suspect it's something server-side, not network-side, unless we have some kind of

Re: [PHP-DEV] Don't silence fatal errors

Hi! > My thought that @ mainly relates to another RFC where errors/warning > are very inconsistently reported or designed (like forcing one to use > @). 8 would be a good candidate to clean that up, like the TypeError > RFC. Cleaning up how PHP does errors would be awesome. After 20+ years of

Re: [PHP-DEV] Don't silence fatal errors

Hi! > I am surely missing use cases because I wonder why we need @, at all? Many functions have to deal with "dirty" data - e.g. loading a file that is supposed to be JSON but may be in fact be invalid in any of the hundreds ways. In some cases, we want full diagnostics, in other cases, just

[PHP-DEV] bugs.php.net problems?

Hi! I am trying to access bugs.php.net and I am getting timeouts all the time today (TLS handshake passes, but no content is delivered). Seems to be something wrong with the site? Could somebody check it? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] RFC Abolish Narrow Margins

Hi! > Thanks for the feedback. I have added a new section to the RFC with the > precise change that will be applied to the voting RFC: > https://wiki.php.net/rfc/abolish-narrow-margins#normative_text I think explaining the changes clearly is a good addition, but I wonder if we should be

[PHP-DEV] Re: RFCs "under discussion"

Hi! > “Inactive”[1] is likely what you're looking for. Inactive implies it's not being worked on... But we certainly could move there at least ones that are "in discussion" for 2 years. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To

[PHP-DEV] RFCs "under discussion"

Hi! Looking at our RFC page, we have over 50 RFCs under discussion. This is obviously not true - and can not be true, really, it's impossible to properly discuss 50+ RFCs at a time, and indeed most of these aren't being currently discussed. I propose to clean up that section and move RFCs for

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Hi! > To me that is the purpose of voting, what you’re saying is like > complaining that in a democracy old people with experience has the > same voting power than young ones. To be clear, PHP user community is not a democracy, neither we want to be. In democracy, every person (marginal cases

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

Hi! >> I want to say that even a small and fairly > simple code change, > which I proposed to push through the bureaucracy, was difficult. > I think this is what Nikita wants to change with this simpler procedure. > More RFCs even on smaller changes, so that more broad input can be > gathered

Re: [PHP-DEV][RFC] Allow void return type variance

Hi! > Recent events convinced me to write this RFC :P > > Please have a read here https://wiki.php.net/rfc/allow-void-variance > > I am targeting all the supported PHP versions because this is mainly to > placate the discontent that arised by PHPUnit enforcing its users to use > void, so

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Hi! > What's the threshold of absurdity here? That we could debate. However, it > is > not 0. (I'd personally put it in the 10-20 range, bearing in mind that not > all of them would vote all the time anyway, just like core developers, but > others may feel differently.) I am not sure

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Hi! Reading the RFC, here's my thoughts: 1. Do we really need different classification of changes? I think having one single vote procedure would have larger benefit, and RFC that fails 2/3 requirement would be suspect anyway. RFCs can have parts - "whether we do it" and "how exactly we do it" -

Re: [PHP-DEV] phpenmod/phpdismod

Hi! >> P.S. I have never understand the need of such tools... >> did it made sense in previous century, where download have a cost ? Enabling/disabling extensions can be useful for many scenario, both in testing and development - such as testing various branches of code, see proper error

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

Hi! >> I want to say that even a small and fairly > simple code change, > which I proposed to push through the bureaucracy, was difficult. We're discussing RFCs. Small and fairly simple code change does not need an RFC. So either: a) this change is indeed small and simple, and does not belong

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

Hi! > Without a required discussion period, there could be slightly more > 'incentive' for RFC authors to respond as quickly as possible, to 'get > the discussion out the way'. I see it exactly opposite - since we have no quorum requirement, declaring the vote as soon as possible if a couple of

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

Hi! > 1. There is no required discussion period. However, if an RFC vote is > opened without leaving enough time for discussion, then voters can and > should vote the RFC down on the grounds of insufficient discussion. I don't think this is a good idea. I see no scenario it improves - there's

Re: [PHP-DEV] phpenmod/phpdismod

Hi! On 2/2/19 12:34 PM, Legale Legage wrote: > These scripts allow you to enable/disable php shared extensions. What you mean by enable/disable? Could you describe a use case for why this script would be used by a developer? Or is this meant for the user - then why the script would be used by

Re: [PHP-DEV] phpenmod/phpdismod

Hi! >> I want to propose including to the bundle phpenmod/phpdismod scripts. These I'm sorry but what these scripts are? What do they do? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] AppVeyor timeouts -- Migrate to Azure Pipelines?

Hi! > I just learned about the Azure Pipelines ( > https://azure.microsoft.com/en-us/services/devops/pipelines/) offering, > which offers open source projects 10 parallel builds with unlimited > minutes. Assuming there's no other catch here, it might be worthwhile to > migrate our Windows CI jobs

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Hi! > 1) Please see my earlier message. The way FIG is structured, one could > extend > voting rights to project representatives, the core committee, both, or > neither. The core committee is 12 people. Project reps are ~36 currently. > Adding 12 people to the voting pool would not

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Hi! I haven't fully read the RFC yet, so I'll come back with more formed opinion about it probably, but wanted to comment about a couple of points here: > Reasoning: If somebody is out of the project for 10 years they probably > lost track on how the language and needs evolved and just voting

Re: [PHP-DEV] RFC Abolish Narrow Margins

Hi! > Let me reply to the last point first, because I think that's really the > crux here: The issue is not that this RFC is very urgent per se, it's that > it has already been delayed numerous times and it is imperative that we > prevent that from happening again. Since this issue was first

Re: [PHP-DEV] Re: patch for imap bug 77153

Hi! > Hi! > > > Anyhow, this is water under the bridge now, and I think we should > issue > > a call for maintainership[4] for ext/imap as soon as possible, since > > this is not the only issue[5] of this unmaintained[6] extension. > > Pierre is listed as maintainer. But

Re: [PHP-DEV] PHAR maintainer?

Hi! > Do I need to request any special git access or just keep doing the usual > PR process? For now, just keep the PRs - ping me and/or this list if they linger too long without review. Eventually I assume we'd just setup you access to ext/phar but PRs seem to be good way for now to start

Re: [PHP-DEV] PHAR maintainer?

Hi! > I've been fixing phar bugs here and there over the last year, and I'm > happy to take on a more diligent process to maintain ext/phar officially. > > Do we have, anywhere, a maintainers guide that talks about the > maintainers' responsibilities? First of all, thanks for volunteering!

Re: [PHP-DEV] Remove zpp variation tests

Hi! > This test passes a certain set of input values of different types to a > function with a zpp string argument and observes the behavior. Of course, > there are also hundreds of other functions that accept strings through zpp > and the behavior is always going to be the same. This is true

Re: [PHP-DEV] Proposal fo "Code-free constructors declaration"

Hi! > Proposed syntax > class A($prop) extends B("BlaBla", $prop) { > } This looks like unobvious magic. PHP approach has traditionally been to avoid unobvious magic, and be explicit about what is happening. This functionality does not seem no be enabling anything different, and seems to be

[PHP-DEV] PHAR maintainer?

Hi! PHAR is pretty widely used component of PHP ecosystem, as I understand, but all people listed as maintainers for the extension haven't been active in the project for a decade. Is there somebody still willing to take care of it? I've been fixing a variety of security issues there, but I don't

Re: [PHP-DEV] [RFC] Reflection for references

Hi! > I'd like to propose the addition of a ReflectionReference class, as > described in the following RFC: > https://wiki.php.net/rfc/reference_reflection Do I understand correctly that the main use case here is to know if two variables (treating this term expansively) point, by reference, to

Re: [PHP-DEV] What to do with ext/xmlrpc?

Hi! > ext/imap should follow the same road. > > BTW, if we want to keep this extension, we need to consider the bundled > library as a fork, maintained by US (and drop support to build using the > system library, if present) > > So, any new volunteer to maintain this extension, will also have

Re: [PHP-DEV] What to do with ext/xmlrpc?

Hi! > So unless a maintainer steps forward, it might be best to deprecate > and/or unbundle ext/xmlrpc. I think we need to do ask for a maintainer, and if nobody steps up, declare it unsupported and unbundle. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development

Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting

Hi! > 2. Even if somebody is using this functionality, the only thing that's > going to happen is that their number display switches from 1,5 to 1.5. > That's a minor UX regression, not a broken application. It's something > that will have to be fixed, but it's also not critical, and for a legacy

Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting

Hi! > So yes, (string)0.3 should return 0.3 in any locale. If we designed it now, without any doubt. But since we have 20 years of history behind... I'm not so sure. > Finally, I don't think that the global locale is the real problem for > PHP. Rather it's PHP locale handling and the fact that

Re: [PHP-DEV] Broken openssl tests on Travis

Hi! > There are 2 ways out: > * This PR https://github.com/php/php-src/pull/3698 aims to solve the > root cause: it modifies tests in order to make them generate > certificates on the fly and always be sure that their expiration date is > in the future (and also unties lots of tests from single

Re: [PHP-DEV] Inconsistent float to string vs. string to float casting

Hi! > Regarding the decimal separator (aka. decimal point), the behavior of > casting float to string is inconsistent with casting string to float. > While the former regards the current locale, the latter always expects a > decimal point regardless of the locale. This breaks round-trips for >

Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

Hi! I like the idea of having such an agile API in the language. But I am, like many others, somewhat worried about security implication of this extension. In theory, it does not give the attacker anything they don't already have - if you have PHP code access, you can probably execute anything

Re: [PHP-DEV] [RFC] Kill proprietary CSV escaping mechanism

Hi! > implementation. Therefore, I suggest to only add support for an empty > $escape parameter (PR #3515), Sounds good. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Don't silence fatal errors

Hi! > It's always been bizarre to me that @ can silence fatal errors, which > has no practical application and makes using @ to silence a lower-level > error potentially hszardous if its targeted function can also produce a > fatal error. Yes, silencing something that kills the script is

[PHP-DEV] Broken openssl tests on Travis

Hi! I am seeing tons of broken openssl tests on Travis CI. Example: https://travis-ci.org/php/php-src/jobs/462367522 All errors seem to be the same: 001+ Warning: stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: 002+ error:14090086:SSL

Re: [PHP-DEV] Built-in classes that cannot be serialized

Hi! > We should migrate such cases to serialize_deny though. I think it's pretty > weird to explicitly implement __wakeup (signalling that yes, you can be > unserialized), and then use it to throw (sorry, I lied). Throwing in __wakeup does not signal that it can be serialized. What it says that

Re: [PHP-DEV] [mini-RFC] Disable opcache per script using "declare(cache=0)"

Hi! >> I'm not sure if you're missing anything fundamental - it's just that >> the preload.php file Dmitry's referring to (the one that's responsible >> to loading all the other files) - is one file that's pretty much by >> definition, will be of no use at any later point in the lifetime of >>

Re: [PHP-DEV] [mini-RFC] Disable opcache per script using "declare(cache=0)"

Hi! > Especially, the main preload.php, usually should be marked, to disable its > caching. Why should it be marked as non-cacheable? I am feeling there's something important I am missing here. Could you explain a bit more about this? -- Stas Malyshev smalys...@gmail.com -- PHP Internals -

[PHP-DEV] Re: patch for imap bug 77153

Hi! > Anyhow, this is water under the bridge now, and I think we should issue > a call for maintainership[4] for ext/imap as soon as possible, since > this is not the only issue[5] of this unmaintained[6] extension. Pierre is listed as maintainer. But given that he is for deprecating it, I guess

Re: [PHP-DEV] Re: patch for imap bug 77153

Hi! > Import the library into core and maintain it or write an alternate from > scratch - IF the functions it provides truly has market demand. Nice suggestion if we had a line of volunteers at our doors asking us to give them something to maintain. We don't. So this is not an option, it's a

[PHP-DEV] Re: patch for imap bug 77153

Hi! > actually the PHP wrapper should not have allowed to pass the mailbox > name verbatim, which would only be reasonable in my opinion, if we were > supporting arbitrary drivers (which we don't). And of course, userland PHP does not do anything with mailbox names. In fact, PHP doesn't even

[PHP-DEV] patch for imap bug 77153

Hi! I've checked in the patch for https://bugs.php.net/bug.php?id=77153, which disables by default rsh/ssh login functionality in IMAP. I assume most people neither know such functionality existed nor need it, but still it's a BC break. The reason why I did it is because IMAP library does not

[PHP-DEV] Re: Package list on bugs.php.net needs update

Hi! > To my knowledge, the list of (pseudo) packages is stored in the > phpbugsdb MySQL database which is hosted on the bugs.php.net server. > There is no further information regarding this machine on the Wiki[1], > though. Anyhow, since Rasmus fixed some encoding issues in this DB not > long

[PHP-DEV] Package list on bugs.php.net needs update

Hi! Who is maintaining the list of available extensions in bugs.php.net? It seems to be out of date (e.g. sodium is missing) and needs to be updated. Is there a list of who has access to this somewhere? Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development

Re: [PHP-DEV] [RFC] Kill proprietary CSV escaping mechanism

Hi! > If we cannot eventually get rid of the escaping for CSV reading (note > that I proposed to keep the possibility to use it until PHP *9*), I > don't think that we should remove it for CSV writing either, since that > would make SplFileObject::setCsvControl() and ::getCsvControl() pretty >

Re: [PHP-DEV] [RFC] Kill proprietary CSV escaping mechanism

Hi! > I hereby put the “Kill proprietary CSV escaping mechanism” under discussion: > > For fputcsv (and generally writing) this is probably OK. I am much more concerned about reading - this may make files generated by PHP be unreadable by php. And

Re: [PHP-DEV] Pre proposal for "Class extension functions"

Hi! > I want to do RFS proposal for new language concept - Class extension > functions. > > Syntax will looks like: > > function DateTime->localTime() { > return $this->format('H:i'); > } I feel this is inviting trouble. If you need additional functionality, why not extend the class? Or

Re: [PHP-DEV] Pre proposal for "Class extension functions"

Hi! > I want to do RFS proposal for new language concept - Class extension > functions. > > Syntax will looks like: > > function DateTime->localTime() { > return $this->format('H:i'); > } I feel this is inviting trouble. If you need additional functionality, why not extend the class? Or

Re: [PHP-DEV] [RFC} Deprecate and Remove ext/wddx

Hi! > We have deprecated and moved to PECL a number of extensions in the > recent past. These were mysql and ereg in PHP 7.0 and mcrypt in PHP 7.2. > I have always understood these moves as "sunsetting" the extensions, in > the sense of strongly discouraging their continued use, as well as >

Re: [PHP-DEV] [RFC} Deprecate and Remove ext/wddx

Hi! > Hmm, I have some doubts that it's okay for users if we remove the WDDX > extension in PHP 7.4 without any deprecation phase. Is there any I think deprecation phase is necessary for features that are being removed. For extension being moved to PECL I do not see any point in annoying the

Re: [PHP-DEV] [RFC} Deprecate and Remove ext/wddx

Hi! About the RFC - I think we can/should move it to PECL in 7.4 but need no deprecation messages if we do. If somebody is using it, deprecation messages would just annoy them, since there's no easy way to switch except rewrite the code to use completely different extension (which would probably

Re: [PHP-DEV] [RFC} Deprecate and Remove ext/wwdx

Hi! > On 9/16/18 12:48 PM, Christoph M. Becker wrote: >> Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under >> discussion. I assume it should be ext/wddx? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] GCC -foptimize-strlen and bug #76510

Hi! So, I am still not sure what the course of action for #76510 is. It's still not fixed, original author of the patch (Xinchen Hui) did not respond to comments on https://github.com/php/php-src/commit/513b0093c2b480bb752fb354012f42c446769486 and we still have 7.3 with non-working phar. I don't

[PHP-DEV] news.php.net dead?

Hi! Looks like news.php.net is not responding. Anybody could check what's up with this? Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: The curious case of the comparable objects.

Hi! > Ah, I forgot that the spec did define it via array comparison. The spec also says in https://github.com/php/php-langspec/blob/master/spec/08-conversions.md#converting-to-array-type:

Re: [PHP-DEV] The curious case of the comparable objects.

Hi! > One of the contributors for the "Because, PHP" page came up with a fun > example where the result of object comparison changes upon observation > of that object. Undefined behavior is undefined :) > 1. Does this matter? (I think so, it's spooky action at a distance) No. There's no

Re: [PHP-DEV] NEWS vs. UPGRADING

Hi! > Do we have clear rules which changes are supposed to be listed in NEWS, > and which ones in UPGRADING? Bugfixes to bugs in the bug tracker and other bugs worth mentioning go to NEWS, so do substantial enhancements. Stuff affecting BC goes to UPGRADING, and also everything that fits into

[PHP-DEV] Re: apache2 buckets API masters needed

Hi! > I need help from somebody who knows how to deal with the details of > Apache2 bucket brigade API for some issue in Apache2 SAPI. I suspect > there's a bug there that can lead to serious problems in certain > situations but not sure how to fix it because my knowledge of proper > ways to

[PHP-DEV] Re: ZEND_ACC_* flags

Hi! > I tried to  fix ZEND_ACC_* flags mess. > > > https://gist.github.com/dstogov/3b6ae377c17524b219670960cf98f8c1 > > > The patch specifies flags meaning, and reorder them according to meaning > and frequency of usage (this allows generation of shorter instructions > on x86). > >

Re: [PHP-DEV] Implementation ideas for adding early warning for mis-use of "parent"?

Hi! > Please note that for traits and closures it's not possible to determine > this at compile time. Why not for closures? I thought closures are bound at definition site, and thus should know everything at compile time? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime

[PHP-DEV] apache2 buckets API masters needed

Hi! I need help from somebody who knows how to deal with the details of Apache2 bucket brigade API for some issue in Apache2 SAPI. I suspect there's a bug there that can lead to serious problems in certain situations but not sure how to fix it because my knowledge of proper ways to handle Apache2

Re: [PHP-DEV] Non-nullable properties

Hi! > I agree with you. If someone really wants to have an "uninitialized" field > on purpose, they should do that using the correct type declaration, i.e.: > > ?MyType $myNullable = null; > > When this was started I asked if it was possible to check types right after > object has been

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