Re: [PHP-DEV] Adding validate_var_array()/validate_input_array() towhich version?

On 05.08.2016 at 02:15, Yasuo Ohgaki wrote: > Pierre suggested the functions should be named "filter_*" and I agree. > > On Fri, Aug 5, 2016 at 6:25 AM, Yasuo Ohgaki wrote: >> Input validation is like assertion shouldn't fail. > > How about > > filter_assert_var() <- validate_var(

Re: [PHP-DEV] Tracing exit()

On 05.08.2016 at 01:37, Sara Golemon wrote: > On Thu, Aug 4, 2016 at 11:10 AM, Bishop Bettini wrote: > >> Or, alternatively, I wonder if a method to convert an exit to an exception >> would be better: > > Eh... That feels less-obvious to me for the reasons you stated in your > OP. I'm not convin

Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions

On 03.08.2016 at 09:59, Lauri Kenttä wrote: > I only saw you mention strpos, preg_match and substr as (slower) > alternatives. However, there's already a function called substr_compare > which is meant for just this kind of comparisons but which is more > general than your RFC. Thanks for pointin

Re: [PHP-DEV] New RFC

On 02.08.2016 at 09:11, Dan Ackroyd wrote: > It has been thought about, and several people are looking at an > implementation of generics: https://wiki.php.net/rfc/generics However, > it seems quite hard to implement. > > I am beginning to wonder if rather than aiming for full support of > generi

[PHP-DEV] Re: [RFC][VOTE] New operator (short tag) for context-dependent escaping

On 30.07.2016 at 17:09, Michael Vostrikov wrote: > Hello. The RFC 'New operator (short tag) for context-dependent escaping' is > now in voting phase. > > https://wiki.php.net/rfc/escaping_operator I just checked out the cde_new branch to verify the behavior of some potential edge cases, but afte

[PHP-DEV] Re: Adding validate_var_array()/validate_input_array() to which version?

On 01.08.2016 at 10:23, Yasuo Ohgaki wrote: > We have filter_var_array()/filter_input_array() currently. They are > designed as filter functions. i.e. They convert offending elements to > NULL/FALSE. Therefore, it's difficult to validate and see if inputs > are valid with specified specifications

Re: [PHP-DEV] Bundled SQLlite3

On 25.07.2016 at 17:36, Anatol Belski wrote: >> -Original Message- >> From: Christoph Becker [mailto:cmbecke...@gmx.de] >> Sent: Monday, July 25, 2016 10:30 AM >> To: Davey Shafik ; Anatol Belski >> Cc: internals@lists.php.net; Ferenc Kovacs >> Sub

Re: [PHP-DEV] RFC Karma Request

On 27.07.2016 at 13:53, Michał Brzuchalski: > 2016-07-27 12:24 GMT+02:00 Christoph Becker : > >> However, that still would require something like >> >> $str[0..mb_strlen($needle)-1] == $needle > > I've been working on range operator some time ago and had p

Re: [PHP-DEV] RFC Karma Request

On 27.07.2016 at 02:55, Davey Shafik wrote: > Ah, I missed that. If we had ranges (e.g. $string[0..4] or $string[-1..4]) > that'd work, but we don't. However, that still would require something like $str[0..mb_strlen($needle)-1] == $needle > Now I see some value in the function, though still

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

On 26.07.2016 at 15:15, Michael Vostrikov wrote: >> The RFC speaks of *operator*, where actually start-tags[1] are meant, to > start with. >> Using the word operator is rather confusing in this context. > > Technically yes, but there are echo operator, so it can be considered as > special constru

Re: [PHP-DEV] Bundled SQLlite3

wrt. new releases and possibly necessary updates in PHP. > On Sun, Jul 24, 2016 at 11:57 PM, Anatol Belski > wrote: > >> Hi Christoph, >> >>> -Original Message- >>> From: Christoph Becker [mailto:cmbecke...@gmx.de] >>> Sent: Monday, July 2

[PHP-DEV] Bundled SQLlite3

Hi! What's our stance on updating the bundled SQLite3? Currently the PHP-5.6 and 7.0 branch have 3.8.10.2, while the PHP-7.1 and master branch have 3.9.2 (sqlite3.h) respectively 3.13.0 (sqlite3.c). The latter would have certainly to be fixed to be consistent, but I have some doubts regarding st

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

On 24.07.2016 at 19:21, Thomas Bley wrote: > I'm not sure if it is a good thing to vote against security enhancements. Most certainly, it is not. :-) -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

On 24.07.2016 at 18:21, Thomas Bley wrote: >> >> >> instead of >> >> > > benefits are using static code analyzers, grep " Having function names with single characters is bad taste and only useful for > obfuscating. Cryptic "operators", however, are not? > The big difference is: > With http

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

On 24.07.2016 at 16:55, Thomas Bley wrote: > In total a good rfc everybody should be happy with. I'm not happy (to put it mildly) with the RFC as it's now. The RFC speaks of *operator*, where actually start-tags[1] are meant, to start with. Using the word operator is rather confusing in this co

Re: [PHP-DEV] Add support for arbitrary HTTP methods

On 22.07.2016 at 12:28, Nikita Popov wrote: > On Fri, Jul 22, 2016 at 2:28 AM, Nazar Mokrynskyi > wrote: > >> I want to bring here question about supporting custom http methods in >> built-in webserver with router script. >> >> The problem is that GET, POST are standard methods and they work fin

[PHP-DEV] Re: Greetings - need orientation about fix

On 20.07.2016 at 21:29, Pablo Sánchez wrote: > I made a small fix/adjustment to lastInsertId on pdo_pgsql on branch 7.0.9. > It builded ok, there's a PR for it (https://github.com/php/php-src/pull/2014) > and I just wondered about if I should apply it on 7.1.0, 5.6.whatever, and > 5.5.whatevertoo.

[PHP-DEV] Re: PHP 5.5 update this week?

On 18.07.2016 at 17:47, Jacob Perkins wrote: > Is there an anticipated release of PHP-5.5 this week? If I'm not mistaken, 5.5.38 is scheduled for Wednesday. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

Hi Scott! On 22.03.2016 at 18:00, Scott Arciszewski wrote: > https://wiki.php.net/rfc/mcrypt-viking-funeral > > The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a 79.3% > favorable response, which exceeds the 2/3 majority by a significant margin. > > Thanks to everyone who vo

Re: [PHP-DEV] [RFC][VOTE] RNG fixes

On 09.07.2016 at 11:18, Leigh wrote: > On Sat, 9 Jul 2016 at 10:16 Christoph Becker wrote: > >> Assuming that "Make array_rand() more efficient" is indeed only about >> performance (and not about fixes for the broken implementation), it >> wouldn't be a

Re: [PHP-DEV] [RFC][VOTE] RNG fixes

On 09.07.2016 at 10:49, Pierre Joye wrote: > On Jul 9, 2016 3:19 PM, "Leigh" wrote: >> >> On Sat, 9 Jul 2016 at 08:48 Pierre Joye wrote: >>> >>> So, I voted no then as it is clear that you do not see a problem to >>> break codes without a single warning or time to adapt before. >>> >>> The other

Re: [PHP-DEV] [RFC][VOTE] RNG fixes

On 09.07.2016 at 10:18, Leigh wrote: > On Sat, 9 Jul 2016 at 08:48 Pierre Joye wrote: > >> So, I voted no then as it is clear that you do not see a problem to >> break codes without a single warning or time to adapt before. >> >> The other sections are fine and voted yes. > > For the part where

Re: [PHP-DEV] [RFC][Vote] ReflectionType Improvements

On 06.07.2016 at 11:23, Rowan Collins wrote: > On 05/07/2016 22:06, Levi Morrison wrote: > >> It would have been great if people actually contributed to the >> discussion before voting phase, but such is life. > > Yes, for my part, I apologise that I didn't pay any attention to this > RFC previo

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

On 06.07.2016 at 23:30, Yasuo Ohgaki wrote: > > On Wed, Jul 6, 2016 at 9:10 PM, Christoph Becker wrote: >> >> Yes, I am aware that the patch uses php_random_bytes(), but what happens >> when it fails, in which case php_session_create_id() returns null[1]? >> W

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

Hi Yasuo! On 06.07.2016 at 03:51, Yasuo Ohgaki wrote: > > On Wed, Jul 6, 2016 at 12:37 AM, Christoph Becker wrote: >> On 05.07.2016 at 16:32, Leigh wrote: >> >>> On 5 July 2016 at 04:02, Pierre Joye wrote: >>>> We can argue about the provided pn

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

On 05.07.2016 at 16:32, Leigh wrote: > On 5 July 2016 at 04:02, Pierre Joye wrote: >> We can argue about the provided pnrng being CS but it is not php's job to >> decide. > > I think we need to drop the concerns about exposing "RNG state". > > A reminder of what php_random_bytes looks at (in or

Re: [PHP-DEV] [RFC][Vote] ReflectionType Improvements

On 05.07.2016 at 15:21, Levi Morrison wrote: > On Mon, Jul 4, 2016 at 10:51 AM, Björn Larsson > wrote: >> Den 2016-06-30 kl. 23:57, skrev Nikita Popov: >>> >>> On Thu, Jun 30, 2016 at 6:06 PM, Levi Morrison wrote: >>> The RFC for improving ReflectionType[1] is now in voting phase. The

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

On 27.06.2016 at 15:28, (Karl Pflästerer ) wrote: > Andreas Heigl writes: > >> Am 27.06.16 um 15:01 schrieb Karl Pflästerer: >>> interface I1 { const C1 = '';} >>> class C3 implements I1 { const C1 = 'c2';} >>> $c3 = new C3; >>> var_dump($c3::C1); >> >> According to https://3v4l.org/jIcs6 it loo

[PHP-DEV] Re: [RFC][Vote] Typed Properties

On 10.06.2016 at 12:38, Joe Watkins wrote: > The vote for typed properties has been restarted. > > Please take part: https://wiki.php.net/rfc/typed-properties I've noticed that the vote for this RFC is still open, even though it states: | Voting started 10th June, ends 24th June 2016.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 22.06.2016 at 17:58, Rasmus Schultz wrote: > Give them a consistent language and new developers will rise to the > occasion - I'm sure of it. You're just not giving them a chance. > Type-hinted properties are a step towards fixing that situation - they > don't add, they *remove* complexity and

Re: [PHP-DEV] New escaped output operator

On 20.06.2016 at 19:19, Rasmus Schultz wrote: >> [1] > > beauty! when can we have that?? :-) Maybe never, but at least somebody would have to pursue the RFC. See also the related discussion from 2013, starting with

Re: [PHP-DEV] New escaped output operator

On 18.06.2016 at 17:44, Rasmus Schultz wrote: >> Add a couple parens and its completely implementable in userland > > If we could autoload functions, I bet that's what everyone would be doing. FWIW, there is an respective RFC draft[1] "lying around". See also . [1]

Re: [PHP-DEV] New escaped output operator

On 19.06.2016 at 19:28, Scott Arciszewski wrote: > Further reading: > https://paragonie.com/blog/2015/06/preventing-xss-vulnerabilities-in-php-everything-you-need-know Thanks! Minor issue: | If you failed to specify ENT_QUOTES and attacker simply needs to pass | " onload="malicious javascript c

[PHP-DEV] Re: Improve GD test suite

On 17.06.2016 at 15:54, Pierre Joye wrote: > The current testing code is under new bsd, so there is no license issue > here. Fine! > I plan to improve the current code to be more useful as well as adding > perceptual diff. My initial idea was to use pdiff. It is under gpl but as > it uses only f

Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x

On 17.06.2016 at 19:58, Rowan Collins wrote: > On 17/06/2016 17:47, Christoph Becker wrote: >> If something is required, one cannot do without it, so there's only one >> course of action, namely to bail out. In my opinion, this is the least >> surprising way to han

Re: [PHP-DEV] [RFC] RNG fixes

On 16.06.2016 at 20:55, Fleshgrinder wrote: > Education is a hard problem that the whole world is struggling with. We > will never achieve it. We will especially not achieve convincing people > of legacy software to change. Heck, we cannot even convince anyone here > to change legacy stuff. Hence,

Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x

On 17.06.2016 at 17:44, Niklas Keller wrote: > 2016-06-17 11:46 GMT+02:00 Christoph Becker : > >> On 17.06.2016 at 10:29, Alexander Lisachenko wrote: >> >>> Nikita, Dmitry, ping. What do you think, shouldn't we replace all >> possible >>> places w

[PHP-DEV] Improve GD test suite

Hi! I like to suggest to improve the current test suite of the gd extension. The main issue I see with the current suite is that many (~ 28) tests use md5() to verify that a drawn image is correct. However, as Pierre mentioned long ago[1], md5() does not work (reliably) for this purpose. An alte

Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x

On 17.06.2016 at 10:29, Alexander Lisachenko wrote: > Nikita, Dmitry, ping. What do you think, shouldn't we replace all possible > places with Fatal Errors with correct throwing of Error exceptions? In > this concrete case it's for "require" operator. > > From what I can see Error will give us m

Re: [PHP-DEV] [RFC] [VOTE] Union types

On 15.06.2016 at 00:51, Levi Morrison wrote: > On Tue, Jun 14, 2016 at 2:43 PM, Zeev Suraski wrote: >> >> On 14 ביוני 2016, at 22:53, Levi Morrison wrote: >> >> I'm personally against Union types because it makes no sense for classes >> >> I've been over this before but I'll repeat it here for c

[PHP-DEV] Re: [RFC] RNG fixes

On 15.06.2016 at 01:08, Tom Worster wrote: > On 6/14/16 12:46 PM, Leigh wrote: > >> The RFC can be found here: https://wiki.php.net/rfc/rng_fixes > > Thanks for putting this together. I am strongly pro on two points and > moderately contra on the other two. I'd prefer separated votes, even > tho

Re: [PHP-DEV] [RFC] RNG fixes

On 14.06.2016 at 21:12, Fleshgrinder wrote: > On 6/14/2016 8:56 PM, Christoph Becker wrote: > >> Yes, I'm aware of that, and that change isn't an issue for me (except >> maybe that it might happen in a minor version). I was responding to >> Richard (Fleshgri

[PHP-DEV] Re: Throwing an Error for require expressions in PHP7.x

On 15.06.2016 at 12:27, Alexander Lisachenko wrote: > For PHP7 we have pretty errors for almost everything, even eval can throw a > ParseError exception, but not for the require expression, because it's > still producing an uncatchable fatal errors: > > try { > require('no.php'); > } catch (T

Re: [PHP-DEV] [RFC] RNG fixes

On 14.06.2016 at 20:46, Leigh wrote: > On Tue, 14 Jun 2016 at 19:14 Christoph Becker wrote: > >> In my opinion, we need at least one random function which yields >> reproducible values. > > Even with the proposed changes both functions will still be capable of > r

Re: [PHP-DEV] [RFC] RNG fixes

On 14.06.2016 at 19:45, Fleshgrinder wrote: > On 6/14/2016 6:46 PM, Leigh wrote: >> The issues I want to bring up for discussion are. >> >> * Replacing mt_rand() and rand() to a strong, modern RNG. >> * Alternatively, fixing the current mt_rand() implementation to make it >> standard >> * Aliasing

Re: [PHP-DEV] Re: [RFC] Iterable

On 13.06.2016 at 17:59, Levi Morrison wrote: > On Mon, Jun 13, 2016 at 5:42 AM, Christoph Becker wrote: >> On 11.06.2016 at 01:37, Aaron Piotrowski wrote: >>> I would like to propose a new iterable pseudo-type that accepts both arrays >>> and objects implementing Trav

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

On 04.06.2016 at 16:37, Bob Weinand wrote: >> Am 4.6.2016 um 16:17 schrieb Christoph Becker : >> >> On 04.06.2016 at 14:15, Bob Weinand wrote: >> >>>> Am 04.06.2016 um 13:45 schrieb Niklas Keller : >>>> >>>> For Aerys\Host it could also

[PHP-DEV] Re: Request for Karma

On 11.06.2016 at 17:19, Fleshgrinder wrote: > I would like to request Karma for the Wiki. > > I would like to write RFCs for the features that I develop and help > others with their RFCs. > > My Wiki username is "fleshgrinder". Ping. IMO it's a no-brainer to grant Wiki karma to Richard. -- C

[PHP-DEV] Re: [RFC] Iterable

On 11.06.2016 at 01:37, Aaron Piotrowski wrote: > I would like to propose a new iterable pseudo-type that accepts both arrays > and objects implementing Traversable. Values accepted by iterable can then be > used with foreach and yield from, or help to reduce type-checking logic in > general. >

Re: [PHP-DEV] [RFC] Throw Exception on Attempt of ConstantRedefinition

On 11.06.2016 at 17:01, Fleshgrinder wrote: > On 6/10/2016 10:06 PM, Dmitry Stogov wrote: >> >> Please review: https://wiki.php.net/rfc/constant_redefinition > > This would be a breaking change in a minor release again. > > -1 > > However +1 for PHP 8. I'm also somewhat concerned with regard t

Re: [PHP-DEV] [RFC] [VOTE] Replace "Missing argument" warning with"Too few arguments" exception

Rowan Collins wrote: > On 06/06/2016 08:22, Dmitry Stogov wrote: > >> This mini RFC has been moved to "Voting" state. Voting >> began on Jun 6 and will close on June 16. >> >> You can find the full RFC at: https://wiki.php.net/rfc/too_few_args >> >> I encourage everyone to read the RFC and cast y

[PHP-DEV] Re: Opinion on function/method name overloading

Dominic Grostate wrote: > As I understand it, using Java-like function overloading in PHP is > undesirable due to hindrance in readability. > > However I'd like to get an opinion on whether it would be received more > favourably if it could provide an actual performance enhancement over hand > ma

Re: [PHP-DEV] Opinion on function/method name overloading

Derick Rethans wrote: > On Mon, 6 Jun 2016, Dominic Grostate wrote: > >> As I understand it, using Java-like function overloading in PHP is >> undesirable due to hindrance in readability. > > Besides it impacting, readability, it will also create a large impact on > performance. > > Right now,

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

On 04.06.2016 at 14:15, Bob Weinand wrote: >> Am 04.06.2016 um 13:45 schrieb Niklas Keller : >> >> For Aerys\Host it could also be solved with an interface that just doesn't >> have any methods. With the disadvantage of callable not being in the same >> signature anymore. > > Also, it requires

Re: [PHP-DEV] [RFC] Replace "Missing argument" warning with "Too fewarguments" exception

On 02.06.2016 at 01:23, Stanislav Malyshev wrote: >> Please take a look into the proposal. >> >> >> https://wiki.php.net/rfc/too_few_args >> >> >> The RFC is extremely simple (both proposal and implementation) and almost >> completely described by the email subject. > > Looks fine to me. I don't

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On 31.05.2016 at 18:55, Fleshgrinder wrote: > On 5/31/2016 6:39 PM, Dmitry Stogov wrote: >> >> $this is still confirm to variable syntax. It's just a special variable. >> I think, we should keep lexical rules unchanged. > > TL;DR $this does conform to syntax but not to basic PHP userland rules >

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 27.05.2016 at 10:27, Rowan Collins wrote: > On 26/05/2016 23:03, Lester Caine wrote: >> On 26/05/16 22:38, Rowan Collins wrote: > // accessing $me->marriage or $me->death returns NULL (because they >> allow nulls) but raises E_NOTICE BUT DateTime currently will not store 'null' - i

Re: [PHP-DEV] Wiki RFC karma request: duncan3dc

On 12.05.2016 at 21:31, Craig Duncan wrote: > On 4 January 2016 at 16:42, Craig Duncan wrote: > >> Hi, >> >> I'd like to create an RFC to change the behaviour of counting objects, as >> discussed in the following pull request: >> https://github.com/php/php-src/pull/1672 >> >> Please can I be gra

Re: [PHP-DEV] [VOTE] 7.1 RMs selection

On 26.04.2016 at 19:10, Peter Cowburn wrote: > Am I correct in understanding that no further candidates or volunteers for > the position will be considered at this time? Anatol mailed the list about the need to have RMs for 7.1 on April, 12th, and suggested to start voting on April, 26th (two wee

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On 26.04.2016 at 16:24, Dmitry Stogov wrote: > At first, I'm glad this implementation is ready. > At least it's possible to analyze its profs and cons. > I'm also sure that both RFCs have their opponents and advocates. > > Now, I just like to make the final voting fair. I'm a bit confused, as th

[PHP-DEV] Re: [RFC] [Discussion] Octal overflow detection

On 19.04.2016 at 01:24, Sara Golemon wrote: > On Tue, Apr 12, 2016 at 7:38 PM, Sara Golemon wrote: >> https://wiki.php.net/rfc/octal.overload-checking >> Because having this expression evaluate to true makes me sad: ("\000" >> === "\400") >> > I haven't heard any responses on this and wanted to b

Re: [PHP-DEV] Re: Improving PHP's type system

On 15.04.2016 at 17:42, Larry Garfield wrote: > I think there's 2 general use cases for union types that would be "good > things", which are different for & and |, and have very little... > intersection. (*yaaa!*) > > The OR case is for cases where the language doesn't support a unified > ca

Re: [PHP-DEV] Re: Improving PHP's type system

On 14.04.2016 at 21:32, Jordi Boggiano wrote: > I don't really think it's much more complex to grasp `Foo|Bar $foo` than > only `Foo $foo`. I mean once you grasp the concept of type hints you > probably have by then a good understanding of || and hopefully can > derive understanding from there. >

[PHP-DEV] Re: Array key access on non-array values - to be made illegal?

On 12.04.2016 at 14:59, Marco Pivetta wrote: > I just stumbled upon behavior that seems to "fail silently" regardless of > its very questionable validity: > > > $a = 1; > > var_dump($a[123]); // NULL, no notice > > https://3v4l.org/b3rDr > > Are there specific reasons why no notice is thrown

Re: [PHP-DEV] [VOTE] var deprecation

On 25.03.2016 at 08:12, Dmitry Stogov wrote: > Java is going to add "var" (http://openjdk.java.net/jeps/286), we are going > to remove... If this JEP is going to pass, "var" will be allowed to replace (local) *type declarations*. In PHP "var" is an alternative *visibility specification*. That'

[PHP-DEV] Re: php wiki

Avtandil Kikabidze wrote: > Hi. I am web developer from Georgia, Tbilisi. About me https://longman.me/cv > How I can register on php wiki? I am trying here > https://wiki.php.net/rfc?do=register but I got error: "That wasn't the > answer we were expecting" > Please help me Please read the instruc

[PHP-DEV] Re: PRNG: Raise warning and/or provide better pseudo random generator?

On 23.02.2016 at 11:41, Yasuo Ohgaki wrote: > Actual range could be determined by PHP_RAND_MAX/PHP_MT_RAND_MAX, but > I heard Windows' PHP_RAND_MAX is only 2^15. Is this correct? Yes, see . > Any comments for adding out of range warnings t

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

On 11.02.2016 at 12:12, Yasuo Ohgaki wrote: > Anyway, all of us know that main source of complaints about PHP is lack > of consistency. Inconsistent APIs across modules are acceptable. It's > modules after all. However, basic language constructs like [] and {} are > better to have predictable/con

[PHP-DEV] Re: Fw: new message

On 11.02.2016 at 03:19, Andrea Faulds wrote: > Why isn't "Sofie Vanderplaetsen" banned from the list yet? It's repeated > spam. I've just made a respective PR: . -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscri

[PHP-DEV] Re: Karma?

On 09.02.2016 at 15:50 Matt Prelude wrote: > Where can I find out how voting karma works? > > I've searched but there appears to be little in the way of a clear guide. > > Keen to get involved, but not sure where to start. Who can vote is described in

Re: [PHP-DEV] Close some old issues

Stanislav Malyshev wrote: >> I don't think having them kept open is providing any value, and it >> makes it harder to find actual issues that need fixing in the issue >> database, so I'd like to close some of them. > > Bug DB triage is a hard, long and often thankless work. I am very > thankful t

Re: [PHP-DEV] Re: Anonymous voting on wiki

Peter Cowburn wrote: > On 11 January 2016 at 12:14, Zeev Suraski wrote: > >> I have no idea if it's related, but is there any chance the patch caused >> some older votes to be broken - at least in how they're displayed? >> Case in point: >> https://wiki.php.net/rfc/voting/vote > > The patch for

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

Thomas Punt wrote: >> I'd like to propose for the inclusion of a digit separator in PHP. This will >> help to promote the readability of numerical literals in code by enabling for >> the underscore character to be used in between digits. >> >> RFC: https://wiki.php.net/rfc/number_format_separator

Re: [PHP-DEV] DOMElement::nodeValue is not W3C conforming

Hi Kalle, hi Matteo, Kalle Sommer Nielsen wrote: > 2015-09-08 23:52 GMT+02:00 Christoph Becker : > >> In bug #70029 it has been reported that DOMElement::nodeValue currently >> does not conform to the W3C specs. Instead of NULL, it returns the >> ::textContent. >>

[PHP-DEV] DOMElement::nodeValue is not W3C conforming

Hi! In bug #70029 it has been reported that DOMElement::nodeValue currently does not conform to the W3C specs. Instead of NULL, it returns the ::textContent. I had committed the patch for master only, to avoid the undesirable BC break for PHP 5.6, but there have been concerns that the BC break m

[PHP-DEV] Re: VCS Account Request: marcio

Márcio Almada wrote: > This is a an updated request, as asked by Tyrael. This time using the > same email address from my previous git commits. For reference: . -- Christoph M. Becker -- PHP Internals - PHP R

Re: [PHP-DEV] Notice on non existing array key (on a boolean)

On 25.08.2015 at 15:48, Sherif Ramadan wrote: > You're right. The notice is triggered by array_push behavior only, which > means that $x = true; echo $x['foo']; doesn't trigger the notice, which is > the same as your code above. Only write operations have historically > resulted in this notice. >

Re: [PHP-DEV] mysqli_get_cache_stats() has vanished

and update the manual. > On Tue, Aug 25, 2015 at 2:25 PM, Christoph Becker wrote: > >> Hi! >> >> Does anybody know what happened to mysqli_get_cache_stats()? >> Apparently, its implementation has vanished between two consecutive >> co

[PHP-DEV] mysqli_get_cache_stats() has vanished

Hi! Does anybody know what happened to mysqli_get_cache_stats()? Apparently, its implementation has vanished between two consecutive commits: ,

Re: [PHP-DEV] libpcre version requirements

Hi Anatol, On 22.08.2015 at 21:21, Anatol Belski wrote: > Hi Christoph, > >> -Original Message----- >> From: Christoph Becker [mailto:cmbecke...@gmx.de] >> Sent: Saturday, August 22, 2015 6:55 PM >> To: Anatol Belski ; 'Nikita Popov' &

Re: [PHP-DEV] libpcre version requirements

Hi Anatol, On 22.08.2015 at 16:52, Anatol Belski wrote: >> Would it be an acceptable compromise for everybody to stick with the current >> *requirements* for now, but to document[1] that PCRE >= 8.10 is >> *recommended* for PHP 5.6 and 7.0? >> > A documentation can never hurt. For the case the re

Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

On 22.08.2015 at 03:02, Pierre Joye wrote: > On Aug 22, 2015 7:39 AM, "Christoph Becker" wrote: >> >> On 21.08.2015 at 12:14, Scott Arciszewski wrote: >> >>> 2. One of the folks in the camp that WANTS an RFC and a drawn out >>> formal decisio

Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

On 21.08.2015 at 12:14, Scott Arciszewski wrote: > 2. One of the folks in the camp that WANTS an RFC and a drawn out > formal decision-making process opens it with a poll. AIUI, that is not how it is supposed to work. Those who want to change existing behavior should make a respective RFC, if co

Re: [PHP-DEV] libpcre version requirements

On 21.08.2015 at 22:37, Anatol Belski wrote: >> -Original Message- >> From: Nikita Popov [mailto:nikita@gmail.com] >> Sent: Friday, August 21, 2015 3:14 PM >> To: Anatol Belski >> Cc: Adam Harvey ; Christoph Becker >> ; PHP internals >&

[PHP-DEV] ext/zip vs. pecl/zip

Hi! How should development and maintenance of the zip extension be handled? Which is the "master" repo? It seems that ext/zip and pecl/zip already have diverged, and IMHO it would be reasonable to keep both repos in sync (or maybe to drop pecl/zip). -- Christoph M. Becker -- PHP Internals -

[PHP-DEV] Re: com php-src: Remove assumption that extensions are in ext/ext-name Fixesalso a weird ln (symlink) hack for phpdbg: acinclude.m4 build/config-stubsbuild/genif.sh build/order_by_dep.awk co

Hi Bob! On 21.08.2015 at 00:13, Bob Weinand wrote: > Commit:82b73fd1e3c53228bb31b75a446114b5fd0cd240 > Author:Bob Weinand Sun, 2 Nov 2014 23:25:49 > +0100 > Parents: a3eed5fbfe24368726906f425b15ce40b5fc36e0 > Branches: master > > Link: > http://git.php.net/?p=php-src.

[PHP-DEV] Re: Syntactical inconsistency with new group use syntax

On 18.08.2015 at 22:47, Arne Blankerts wrote: > while playing around with the new group use syntax, I stumbled upon an > inconsistency of which I'm not sure whether or not it is expected. > For the "classic" syntax, while technically pointless, a leading \ for > the name is considered valid and wo

[PHP-DEV] Re: com php-src: Fixed tests(I am not sure, these tests seems strange, anywayit passes locally now): tests/run-test/test005.phpttests/run-test/test008.phpt tests/run-test/test008a.phpt

On 13.08.2015 at 16:31, Xinchen Hui wrote: > Commit:69dbfa8e9f7a292880a639cad647d8ef8cf28a5c > Author:Xinchen Hui Thu, 13 Aug 2015 22:31:59 > +0800 > Parents: 896cb514995ff98cb03257d88fc7b55aab5186f9 > Branches: master > > Link: > http://git.php.net/?p=php-src.git;a=co

[PHP-DEV] Re: [DOC-CVS] svn: /phpdoc/en/trunk/reference/datetime/datetimeimmutable/construct.xml

On 14.08.2015 at 17:18, Peter Cowburn wrote: > On 14 August 2015 at 13:49, Christoph Michael Becker wrote: > >> cmb Fri, 14 Aug 2015 12:49:32 + >> >> Revision: http://svn.php.net/viewvc?view=revision&revision=337451 >> >> Log: >> fixed wrong parameter nam

[PHP-DEV] Re: PCRE jit security hole WAS PCRE JIT stack size limit

On 13.08.2015 at 17:00, Dan Ackroyd wrote: > On 23 July 2015 at 11:07, Christoph Becker wrote: >> PHP7 supports PCRE's JIT compilation of patterns by default, which >> mostly works fine. However, there are issues when the matching exceeds >> the JIT stack limit, see

Re: [PHP-DEV] libpcre version requirements

On 12.08.2015 at 08:44, Anatol Belski wrote: >> -Original Message- >> From: Christoph Becker [mailto:cmbecke...@gmx.de] >> Sent: Tuesday, August 11, 2015 11:09 PM >> To: Anatol Belski ; 'PHP internals' >> >> Subject: Re: [PHP-DEV] libpcre ver

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

On 10.08.2015 at 11:57, Craig Francis wrote: > You only have to skim read things like the second comment (with 27 up votes) > on the PDO prepare page to see that these problems are happening all the time: > > > http://php.net/manual/en/pdo.prepare.php#111458 > SELECT * FROM users WH

[PHP-DEV] Re: com php-src: Export argument type checking functions:Zend/zend_execute.c Zend/zend_execute.h

Hi Dmitry, On 11.08.2015 at 18:11, Dmitry Stogov wrote: > Commit:a658465ef2ff7e47fc93b4988e4caa6f42d4ae49 > Author:Dmitry Stogov Tue, 11 Aug 2015 19:11:21 > +0300 > Parents: 5b017ba8be49fc0a07d4e5e1e43f1d0e635f336f > Branches: master > > Link: > http://git.php.net/?p=

Re: [PHP-DEV] libpcre version requirements

On 11.08.2015 at 22:46, Anatol Belski wrote: >> -Original Message- >> From: Christoph Becker [mailto:cmbecke...@gmx.de] >> Sent: Tuesday, August 11, 2015 6:46 PM >> To: PHP internals >> Subject: [PHP-DEV] libpcre version requirements >> >> W

Re: [PHP-DEV] libpcre version requirements

On 11.08.2015 at 22:08, Yasuo Ohgaki wrote: > On Wed, Aug 12, 2015 at 4:59 AM, Yasuo Ohgaki wrote: > >> Distributions prefer to use system's libraries. I suppose question is if >> PHP >> supports older systems such as RHEL/CentOS 5 or not. They are used widely. >> I prefer to support them if it

[PHP-DEV] Re: include/require function declaration.

On 11.08.2015 at 19:38, Florian BERBAR wrote: > I try to understand the internals implementation of include and require > functions. I've reading the sources code in search of the answer but i > didn't found those declarations. Does anyone can give me the file where > those statements are ? I sug

Re: [PHP-DEV] libpcre version requirements

On 11.08.2015 at 19:01, Adam Harvey wrote: > On 11 August 2015 at 09:46, Christoph Becker wrote: >> What is the minimum libpcre version that is supported as external >> libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 >> (2006-02-06), but is this still valid and

[PHP-DEV] libpcre version requirements

Hi all! What is the minimum libpcre version that is supported as external libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still valid and do we really have to support such old versions? I'm asking because of bug #70232 which can easily be fixed, but that re

Re: [PHP-DEV] realpath() on MacOSX doesn't normalize the case of characters

On 05.08.2015 at 17:30, Nicolas Grekas wrote: >> For windows, there is no path normalization either btw. It would makes >> realpath more expensive. > > I don't know what you mean by "no path normalization", but as far as the > case is concerned, there IS normalization: > var_dump(realpath(strtolo

Re: [PHP-DEV] Move internals discussion to a better medium

On 04.08.2015 at 19:30, Stephen Coakley wrote: > On 08/04/2015 11:36 AM, Ferenc Kovacs wrote: > >> maybe it just me, but it seems to me, that every time this idea is >> brought >> up, not many people from the actual participants of the list speak up, >> but >> bunch of people who never before sent

  1   2   3   >