Re: [PHP-DEV] How to indicate support for unimplemented part of an RFC

[Rowan Collins]

On 14/06/2016 20:11, Leigh wrote:

On Mon, 13 Jun 2016 at 22:30 Matthew Browne  wrote:


Hi,
What is the proper way to express support for an item that's not an
official part of an RFC but is listed as an idea for future
consideration? Specifically I wanted to give my "+1" for covariant
return types which are mentioned in passing in this RFC:
https://wiki.php.net/rfc/return_types.



I think you'd go ahead and create an RFC for it :)



In this particular instance, it may be more to the point to create an 
*implementation* of it.


The reason it was omitted was not for lack of desire, but due to 
practical problems of how to make it work. See for instance 
http://marc.info/?l=php-internals&m=142791636808421&w=2


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Alexander Lisachenko]

Hi, internals!

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 (Throwable $e) {
echo 'Catch!';
} finally {
echo 'Finally?';
}
// Warning: require(no.php): failed to open stream: No such file or
directory
// Fatal error: require(): Failed opening required 'no.php'

See https://3v4l.org/sQeAQ for live demo. What are the reasons not to throw
Error here? Looks like an oversight for me.

Can we also add FileNotFoundException and use it for all file functions to
avoid silencing with "@" operator? Then require expression can throw an
Error with nested FileNotFoundException.

Thoughts?

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

[Pierre Joye]

On Tue, Jun 14, 2016 at 11:46 PM, Leigh  wrote:
> Hey Internals,
>
> I realise I'm cutting it close with this one, but I want to propose some
> changes to our standard random number generators.
>
> The downside of this proposal is that our RNGs (rand() and mt_rand()) are
> seedable and reproduce identical streams (platform dependant) for any given
> seed. However their implementations are broken or inconsistent, so we need
> to weigh up the cost of changing these sequences versus having solid
> implementations.
>
> It is my opinion that if we are going to make any changes to these
> functions, we should make all of the changes at the same time and avoid any
> future disruption to their output.
>
> The RFC contains a few proposals, some of them depend on each other while
> others are standalone. Throughout the discussion phase I hope to reduce the
> number of proposals down to a consensus we can vote on in two weeks time.
>
> I will release a patch when I have a better feeling for the direction we
> want to take.
>
> The issues I want to bring up for discussion are.
>
> * Replacing mt_rand() and rand() to a strong, modern RNG.

I do not think this is a good option, if by strong you mean another kind of RNG.

> * Alternatively, fixing the current mt_rand() implementation to make it
> standard

That sounds more reasonable. An option (please no ini as it is a
programatic flow feature, not a php configuration problem) to keep the
old behavior for BC. Having to add an option for 7.1 or 7.2+ is
reasonable enough for the cases where the current seed and predictable
sequences are desired (same data generations for example using one
seed for example).

> * Replacing insecure uses of php_rand() with php_random_bytes()
> * Making the array_rand() algorithm more efficient

Indeed

> The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
>
> If anyone knows of other fixes that should be made at the same time but I
> have overlooked, please let me know so I can get them included.

Also in the replies to this thread I see the word "crypto" mixed with
mt_rand/rand. It does not make sense to me. I agree that some apps
misused these functions as crypto safe RNG, some may even work around
issues and do not want to change their code to use reliable
alternatives. However this is a documentation/education issue. There
is no need to make mt_rand/rand crypto safe but there is a use for a
reliable implemantion of mt_rand.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Rowan Collins]

On 15/06/2016 11: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


Agree that this would be good. I don't know if there's a technical 
reason against it, or just that nobody's got round to it yet.




Can we also add FileNotFoundException and use it for all file functions to
avoid silencing with "@" operator?


This, however, is a completely different topic. It's one that's come up 
before, but not gained much traction, because it breaks an extremely 
large amount of existing code. I would suggest having a look in the list 
archives, and raising this as another topic if you can come up with a 
good plan for how it should work.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Pierre Joye]

On Tue, Jun 14, 2016 at 11:17 PM, Fleshgrinder  wrote:
> On 6/14/2016 12:43 PM, Dmitry Stogov wrote:
>> Hi,
>>
>> Just take into account, that 7.0 was released more than after 10
>> years of php-5 life, and of course we don't have any plans or goal
>> for 8.0 yet.
>>
>> Waiting another 10 years for fixing inconsistencies, that we "missed"
>> in 7.0, would limit our progress on bytecode and VM optimizations
>> targeted to 7.1 and future progress in next minor versions.
>>
>
> Isn't that just an excuse to creep in breaking changes? We all
> understand the goal here and we all are in favor of it. The problem is
> that it still is a breaking change. It would be better to elevate the
> E_INFO to an E_WARNING and create that PHP-8.0 branch with the actual
> error and start planning the 8.0 release.
>
> PHP 5.4 was already like a PHP 6.0, it was simply not called that way.
> Why not learn from past mistakes and improve upon them?
>
> Having a release cycle that is faster than the current one would help
> users and companies. People could plan according to it. People would
> know what to expect and it would most certainly make it easier for all
> of use to plan and align.

This is the plan. We did not manage to stick major releases in the
release process RFC as it was already very hard to get a compromise.

As I think it is a bit too early to plan 8.0, we should definitively
start to think about what we want/would like to focus. It can be like
7.0, no major breakages but on spot improvements that are not possible
in 7.x

About the BC breaks, the RFCs do not define them clearly. It is a
complex topic. Bugs fixes can be seen as BC breaks (old enough bugs
become features). However new warninngs (except fatal) are not
considered BC breaks. Behavioirs changes are and that's why some fixes
or improvements require a RFC. I understand that a RFC allowing to
break BC is not good thing from a policy point of view, but as far as
I can tell, the ones we chosen so far were more than welcome by the
communities, which is a good sign about our handling of BC breaks.

I also understand the needs to change, update, optimize or clean our
edge cases to open the path to JIT and the likes. However I would be
very careful about that, and Dmitry and the team are very careful. I
also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Christoph Becker]

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 (Throwable $e) {
> echo 'Catch!';
> } finally {
> echo 'Finally?';
> }
> // Warning: require(no.php): failed to open stream: No such file or
> directory
> // Fatal error: require(): Failed opening required 'no.php'
> 
> See https://3v4l.org/sQeAQ for live demo. What are the reasons not to throw
> Error here? Looks like an oversight for me.

This had recently been reported as feature request, and my reply was:

| With regard to your example: if a file is *required* and it can't
| be included, it doesn't make much sense to go on. If on the other
| hand the file is not really required, just `include` it.

[1] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Christoph Becker]

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 (Fleshgrinder) who suggested to remove rand() and mt_rand()
>> alltogether, because there is random_int().
>
> Call me ignorant but is this required in typical web applications?
> Couldn't we move this functionality to PECL? I mean, it is required in
> games but other than that.

I don't know, but I can image that it is (test suites come to mind).  Of
course, it might be an option to move the functionality to PECL, but on
the other hand, what would we gain?  For users, however, that might be a
major pain; consider software which runs on shared hosting.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-06-15

[lp_benchmark_robot]

Results for project PHP master, build date 2016-06-15 06:30:06+03:00
commit: 3389c2e
previous commit:14e790a
revision date:  2016-06-14 22:39:18+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.15% -0.25%  1.18%  
  6.28%
:-|   Drupal 7.36 cgi -T1  0.16% -0.22%  0.08%  
  4.66%
:-|   MediaWiki 1.23.9 cgi -T5000  0.07% -0.19%  1.50%  
  3.17%
:-|   bench.php cgi -T100  0.01%  0.50% 28.50%  
 -0.12%
:-|  micro_bench.php cgi -T10  0.01%  0.95%  4.87%  
  3.09%
:-(  mandelbrot.php cgi -T100  0.04% -1.38% 30.65%  
 -0.63%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2016-06-15/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Christoph Becker]

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
> though I don't have a vote. I numbered the 4 bullets in your intro 1
> thru 4.
> 
> 4. Insecure usage. I think we should replace the internal insecure uses
> of php_rand(). I can't see a reason not to.
> 
> 3. Poor scaling of bounded outputs. I think RAND_RANGE() should be
> fixed. Users surely expect unbiased distribution. There's a BC argument
> but the bug is pretty serious. I think this should apply to array_rand()
> too.
> 
> 1. Incorrect implementations.
> 
> I don't think we should dictate that programs currently using mt_rand()
> shall use in future use MT19937 any more than we should dictate that
> XorShift64 or any other PRNG better fits their requirements.
> 
> The incorrectness of the mt_rand() implementation with respect to its
> documentation can be fixed either in the code or in the docs. Given
> that, as far as we know, mt_rand()'s byte-stream looks like a decent
> PRNG[1] it's not clear that the actual MT19937 sequence is more
> important that backward compatibility. I for one think it's very unlikely.
> 
> [1] https://gist.github.com/tom--/a12175047578b3ae9ef8
> 
> I also don't think we should assume the responsibility of correcting
> people's insecure programs using rand() or mt_rand() (e.g. for keys,
> IVs, salts) by changing the algorithm. Programs this bad need more
> rework than we can provide. These functions have had scary-colored
> cautions on them for a long time.
> 
> 2. Roughly the same arguments applies to rand(). The function is PHP's
> API to the OS's rand(3). There's value to that and probably people who
> rely on it.

Hm, at least traditionally the rand() implementation on Windows is
limited to non-negative short ints (16-bit signed), what appears
generally limited, and might make it hard to write portable code.  On
the other hand a developer could use mt_rand() instead, and we could
document that rand() is a rather low-level non-portable API.

> Summarizing 2. and 3. it's not clear what we fix in the real world with
> the proposed changes to rand() and mt_rand(). But I do see BC breakage.
> I would prefer to fix these bugs the docs.
> 
> 
> With respect to PRNGs completely new to PHP (you mentioned Xoroshiro128+
> and PCG), I would prefer completely divorce this question from the bugs
> discussed above. If some PHP users need efficient implementations of
> such algorithms then I would urge whoever wants to write them to use a
> new API and to provide them via PECL. In software, "better" is always
> with respect to context. While there are specific, well-known uses for
> random numbers (e.g. crypto) where we can make recommendations, in
> general we cannot.

I agree to every said (except where noted).

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Jordi Boggiano]

On 15/06/2016 11:41, Pierre Joye wrote:

I also understand the needs to change, update, optimize or clean our
edge cases to open the path to JIT and the likes. However I would be
very careful about that, and Dmitry and the team are very careful. I
also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.


+1 to that, it would be much better to introduce BC (strong/er) warnings 
in 7.1/7.2 and then if needed branch off 8.0 already so that JIT work 
can happen there with the BC warnings (and related features) removed. 
8.0 could then come a year or two after 7.1 depending on how the JIT 
work progresses. This would keep the "BC promise" intact instead of 
going back to cowboy php days.


We are finally seeing more rapid PHP version adoption and I think it 
would be a shame to break the trust PHP gained in the last few years of 
stable and predictable releases.


Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Tom Worster]

On 6/15/16 6:33 AM, Pierre Joye wrote:

> * Alternatively, fixing the current mt_rand() implementation to make it
> standard

That sounds more reasonable. An option (please no ini as it is a
programatic flow feature, not a php configuration problem) to keep the
old behavior for BC. Having to add an option for 7.1 or 7.2+ is
reasonable enough for the cases where the current seed and predictable
sequences are desired (same data generations for example using one
seed for example).



Hi Pierre,

I'm glad you mentioned a compatibility mode. Let's say we would offer:

int mt_rand ( $mode = MT_RAND_COMPAT )

int mt_rand ( int $min, int $max, $mode = MT_RAND_COMPAT )

MT_RAND_COMPAT = 1

MT_RAND_MT19937 = 2

A PHP user needs to make the right choice of what to use in their 
situation. A technical description of the modes would be confusing and 
unhelpful to most users. I have no idea how to document this simply, 
honestly and accurately, and without jumping to conclusions about 
suitability.


This is why I think a compat/correct mode switch doesn't improve PHP. 
It's inconsistent with the spirit set out in the preamble of "PHP RFC: 
Your Title Here"[1].


[1] https://wiki.php.net/rfc/template

Similarly, the $mode arg allows us to add MT_RAND_XOROSHIRO128_PLUS or 
whatever (interesting to some of us, more "modern", perhaps arguably 
more "strong" or are otherwise "better") aren't improvements to PHP 
unless users are asking for them.


Tom


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP allocating too much memory

[Peter LeBrun]

Hi -

I'm getting the following error in php7.0.5:

Fatal Error: Allowed memory size of 536870912 bytes exhausted (tried to
allocate 140729445144864 bytes)

If it's relevant, we're using dblib+freetds.

I can't reproduce the issue deterministically; the best I can do is to
repeatedly curl an endpoint and something like 30% of the requests will
fail due to the above error.

The weirdest part about this is that PHP is somehow trying to allocate
140TB of memory.

Has anyone seen anything like this?  Any insights would be appreciated.

Thanks,

Peter

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

[Jordi Boggiano]

On 15/06/2016 13:41, Tom Worster wrote:

int mt_rand ( $mode = MT_RAND_COMPAT )

int mt_rand ( int $min, int $max, $mode = MT_RAND_COMPAT )

MT_RAND_COMPAT = 1

MT_RAND_MT19937 = 2

A PHP user needs to make the right choice of what to use in their
situation. A technical description of the modes would be confusing and
unhelpful to most users. I have no idea how to document this simply,
honestly and accurately, and without jumping to conclusions about
suitability.

This is why I think a compat/correct mode switch doesn't improve PHP.
It's inconsistent with the spirit set out in the preamble of "PHP RFC:
Your Title Here"[1].

[1] https://wiki.php.net/rfc/template

Similarly, the $mode arg allows us to add MT_RAND_XOROSHIRO128_PLUS or
whatever (interesting to some of us, more "modern", perhaps arguably
more "strong" or are otherwise "better") aren't improvements to PHP
unless users are asking for them.


Just a thought here, if the goal is to provide a better interface, 
wouldn't it be better to use OO for this? Not because OO is better, but 
because it would avoid having problems if two mt_rand-using pieces of 
code are executed concurrently.


Something like this:

$gen1 = new SeededRandom(MT_RAND_MT19937, 23);
$gen2 = new SeededRandom(MT_RAND_MT19937, 23);
$gen1->rand(); // or get()? generate()?
$gen1->rand();
$gen2->rand(); // returns the same as the first call as both use seed 23

With the current situation, if you add a library that relies on mt_rand 
you can suddenly break your ability to get consistent numbers.


Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP allocating too much memory

[Jordi Boggiano]

On 15/06/2016 14:01, Peter LeBrun wrote:

Hi -

I'm getting the following error in php7.0.5:

Fatal Error: Allowed memory size of 536870912 bytes exhausted (tried to
allocate 140729445144864 bytes)

If it's relevant, we're using dblib+freetds.

I can't reproduce the issue deterministically; the best I can do is to
repeatedly curl an endpoint and something like 30% of the requests will
fail due to the above error.

The weirdest part about this is that PHP is somehow trying to allocate
140TB of memory.

Has anyone seen anything like this?  Any insights would be appreciated.


I have hit that due to an opcache bug in handling of constant arrays on 
classes.


Something like: class Foo { const BLA = []; }

This was fixed in 5.6.15 [1] which came out before PHP7 though, so I'd 
imagine that isn't the exact problem you are hitting, but it might be 
related.


[1] https://bugs.php.net/bug.php?id=70795

Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Christoph Becker]

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 completeness:
>> this is not true.
>>
>> There are more than enough constructs in PHP to handle all these use cases,
>> and handle them nicely.  We don't need specialized constructs for every use
>> case.
> 
> To clarify here, you are saying we don't need unions because they are
> a special case, yes? But you previously stated you are in favor of
> special casing the language types such as numeric?
> 
> These are at odds.

In my opinion, there have to be always compromises when designing a
language for practical purposes.  Theoretically, it would not even be
necessary for PHP to have scalar types; everything could be done with
(immutable) objects as well.  However, we do have scalar types, and
these are likely to stay, so it seems reasonable to me to add a few
special cases to our type system covering this issue (say, Stringable,
Iterable, numeric, Invokable).

Adding union types as a general mechanism, on the other hand, adds a new
level of complexity for the user which is orthogonal to the classical OO
type system, at least when type definitions will be added, what I
estimate will not take long, due to the verbose inline union typing.
And that is easily going to get out of hand, because independent
libraries might introduce their own LIB\numeric, for instance,
potentially with slightly different definitions (e.g. with or without GMP).

Finally, I don't consider |false a very reasonable thing, because the
respective functions could return a nullable type as well, what would in
my opinion be better anyway for the famous strpos(), which requests the
position of $needle in $haystack, what should be either a numeric index
or NULL (== not present).  And at least built-in functions may also
return NULL for wrong argument types, which would require to type their
return values as X|false|null to be exact.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP allocating too much memory

[Johannes Schlüter]

Hi,

On Wed, 2016-06-15 at 09:01 -0400, Peter LeBrun wrote:
> I'm getting the following error in php7.0.5:
> 
> Fatal Error: Allowed memory size of 536870912 bytes exhausted (tried to
> allocate 140729445144864 bytes)

The huge number 140729445144864 is most likely consequence of an
overflow.

Can you try to reproduce this with a debug build? - Those make the error
message a bit more verbose by stating which emalloc call caused this.
Probably one can receive more info by attaching gdb (or another
debugger) to the PHP process

i.e.

$ gdb -p 1234   # 1234 is the PID of a PHP process
(gdb) source /path/to/php-src/.gdbinit
(gdb) break zend_mm_safe_error
(gdb) run

now hit PHP a few times

(gdb) bt
[dumps system stack trace]
(gdb) zbacktrace
[dumps PHP-level stack trace, gdb macro defined in gdbinit loaded above]


johannes




signature.asc
Description: This is a digitally signed message part

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

[Zeev Suraski]

> -Original Message-
> From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On Behalf
> Of Levi Morrison
> Sent: Wednesday, June 15, 2016 1:51 AM
> To: Zeev Suraski 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] [RFC] [VOTE] Union types
> 
> On Tue, Jun 14, 2016 at 2:43 PM, Zeev Suraski  wrote:
> > There are more than enough constructs in PHP to handle all these use
> > cases, and handle them nicely.  We don't need specialized constructs
> > for every use case.
> 
> To clarify here, you are saying we don't need unions because they are a
> special case, yes? But you previously stated you are in favor of special 
> casing
> the language types such as numeric?
> 
> These are at odds.

They're not.  Let me supplement what I said:

We don't need specialized constructs for every use case;  They make sense for 
ultra-common ones only, and only if the added benefit (compared to doing it 
using the methods currently available) outweighs the increased cognitive burden.

Hence, 'numeric' makes perfect sense, while a generic Union Types feature does 
not.

Zeev

Re: [PHP-DEV] PHP allocating too much memory

[Rowan Collins]

On 15/06/2016 14:01, Peter LeBrun wrote:

The weirdest part about this is that PHP is somehow trying to allocate
140TB of memory.


I've seen numbers like that a few times - always around 140TB, but the 
exact number varies. I assume it's an overflow (or underflow?) 
somewhere, but the exact mechanism escapes me. (It's close to 2^47, but 
not very close; I've got examples logged as "low" as 140090229815192, 
and I think I've seen under 140 trillion.)


Apart from sheer curiosity of where this magic number comes from, I 
wonder if there is some sanity check missing in the memory manager to at 
least display a different error message...


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Tom Worster]

On 6/15/16 9:04 AM, Jordi Boggiano wrote:


Just a thought here, if the goal is to provide a better interface,


Hi Jordi,

Iiuc, Leigh's goal, which I support, is to fix known bugs. It is not to 
provide a better interface.


I already suggested that if people want new RNGs or a new API then we 
should divorce that discussion from the bug fixes. Let's not use this 
RFC or thread for that.


Tom


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP allocating too much memory

[Thomas Hruska]

On 6/15/2016 6:07 AM, Jordi Boggiano wrote:

On 15/06/2016 14:01, Peter LeBrun wrote:

Hi -

I'm getting the following error in php7.0.5:

Fatal Error: Allowed memory size of 536870912 bytes exhausted (tried to
allocate 140729445144864 bytes)

If it's relevant, we're using dblib+freetds.

I can't reproduce the issue deterministically; the best I can do is to
repeatedly curl an endpoint and something like 30% of the requests will
fail due to the above error.

The weirdest part about this is that PHP is somehow trying to allocate
140TB of memory.

Has anyone seen anything like this?  Any insights would be appreciated.


I have!

You wouldn't, by any chance, have ODBC in the mix?  The libraries you 
mention seem to indicate that you might be using ODBC.  There is a known 
issue with mixing 32-bit and 64-bit binaries with PHP and ODBC.  I don't 
remember all the details, but mixing 32-bit and 64-bit binaries will see 
things like NULL values as not NULL behind the scenes and do the wrong 
thing whereby PHP eventually attempts to allocate a ridiculous amount of 
RAM (e.g. a -1 value gets translated badly and assumes that it is the 
amount of RAM to allocate).  I've seen allocation requests for upwards 
of 14 exabytes of RAM before - the amount varies but is always 
laughable.  From what I can tell, NULL values in the query results will 
always trigger the problem and, even if you can guarantee that there are 
no NULL values in ANY of the query results, the issue still arises at a 
pretty significant rate due to bit-depth differences.


Unfortunately, due to the way ODBC itself was created and functions, 
there is no easy fix within a mixed binary environment.  To *correctly* 
fix the problem, you've got to match the bit-depths of ALL of the 
binaries involved - that is, either all 32-bit or all 64-bit - which is 
not always possible.  The alternative is to use the ugliest hack ever: 
Execute a separate PHP process for running each database query that 
continually retries when it fails and just live with the high failure 
rates.  Guess which solution I used?  Fortunately, in my case, the 
number of queries being run was quite limited and on a set schedule. 
You might not be so lucky.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP allocating too much memory

[Michael Felt]

On 15-Jun-16 15:55, Rowan Collins wrote:

On 15/06/2016 14:01, Peter LeBrun wrote:

The weirdest part about this is that PHP is somehow trying to allocate
140TB of memory.


I've seen numbers like that a few times - always around 140TB, but the 
exact number varies. I assume it's an overflow (or underflow?) 
somewhere, but the exact mechanism escapes me. (It's close to 2^47, 
but not very close; I've got examples logged as "low" as 
140090229815192, and I think I've seen under 140 trillion.)
In hex: 7F694C627798 - so apparently 7F694 is common to 
all.
FYI: I have seen similar issues with mixed environments (32 and 64-bit) 
- at this point I am surprised that you can even dlopen() both sizes (my 
OS now refuses to dlopen() 32-bit modules aka shared libraries when 
64-bit application and v.v.)
Apart from sheer curiosity of where this magic number comes from, I 
wonder if there is some sanity check missing in the memory manager to 
at least display a different error message...


Regards,



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Rowan Collins]

On 15/06/2016 12:38, Jordi Boggiano wrote:

On 15/06/2016 11:41, Pierre Joye wrote:

I also understand the needs to change, update, optimize or clean our
edge cases to open the path to JIT and the likes. However I would be
very careful about that, and Dmitry and the team are very careful. I
also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.


+1 to that, it would be much better to introduce BC (strong/er) warnings
in 7.1/7.2 and then if needed branch off 8.0 already so that JIT work
can happen there with the BC warnings (and related features) removed.
8.0 could then come a year or two after 7.1 depending on how the JIT
work progresses.


Dmitry, Stas, do you think something like this could work? Could we have 
a "php.next" preview branch with lots of performance work going on, 
especially if a lot of it is focused around opcache anyway?


- You could still raise RFCs for expected breaking changes, to make sure 
you have approval for a language change before investing time depending 
on it, but set their target as 8.0.
- Users would know what to expect from each release, and have plenty of 
notice to make their code "php8-ready".
- Even if we're not ready to turn on JIT, an accumulation of 
improvements would give users a more visible incentive to handle any 
compatibility problems.
- Grander plans that don't happen to be ready at the same time can 
always go into 9.0 instead.




This would keep the "BC promise" intact instead of
going back to cowboy php days.


This. A hundred times this. Please don't let's make it harder to go from 
7.0 to 7.1 than it was from 5.6 to 7.0.



Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Small proposal for ReflectionType improvements

[Levi Morrison]

As mentioned a day or two ago have a few proposed improvements for
ReflectionType:

https://wiki.php.net/rfc/ReflectionTypeImprovements

It's pretty small but very useful. It has a small BC with the
__toString representation of parameters with a default value of null
to reflect the new nullability syntax.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Fleshgrinder]

On 6/15/2016 12:27 PM, 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 (Throwable $e) {
> echo 'Catch!';
> } finally {
> echo 'Finally?';
> }
> // Warning: require(no.php): failed to open stream: No such file or
> directory
> // Fatal error: require(): Failed opening required 'no.php'
> 

This is exactly how require is meant to work, just use include as
Christoph said already. These are two distinct features for a reason.

On 6/15/2016 12:27 PM, Alexander Lisachenko wrote:
> Can we also add FileNotFoundException and use it for all file functions to
> avoid silencing with "@" operator? Then require expression can throw an
> Error with nested FileNotFoundException.
> 

We definitely need this but it cannot go into PHP 7.0.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP allocating too much memory

[Trevor Suarez]

On Wed, Jun 15, 2016 at 11:34 AM, Michael Felt  wrote:

>
>
> On 15-Jun-16 15:55, Rowan Collins wrote:
>
>> On 15/06/2016 14:01, Peter LeBrun wrote:
>>
>>> The weirdest part about this is that PHP is somehow trying to allocate
>>> 140TB of memory.
>>>
>>
>> I've seen numbers like that a few times - always around 140TB, but the
>> exact number varies. I assume it's an overflow (or underflow?) somewhere,
>> but the exact mechanism escapes me. (It's close to 2^47, but not very
>> close; I've got examples logged as "low" as 140090229815192, and I think
>> I've seen under 140 trillion.)
>>
> In hex: 7F694C627798 - so apparently 7F694 is common to
> all.
> FYI: I have seen similar issues with mixed environments (32 and 64-bit) -
> at this point I am surprised that you can even dlopen() both sizes (my OS
> now refuses to dlopen() 32-bit modules aka shared libraries when 64-bit
> application and v.v.)
>
>> Apart from sheer curiosity of where this magic number comes from, I
>> wonder if there is some sanity check missing in the memory manager to at
>> least display a different error message...
>>
>> Regards,
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I've seen this bug come up with the SOAP extension. I saw it happen when
instantiating a SoapClient or SoapServer when the constructor tries to load
a WSDL file under very certain circumstances. If the SOAP WSDL caching is
on (if `soap.wsdl_cache = 1`), the WSDL file is cached (or is attempting to
be cached) or the WSDL must be downloaded, and the file-system is full,
then this crazy overflow can happen. I believe it's due to the WSDL's
becoming corrupted due to the file-system halting the write of the file and
PHP not cleaning up the improper write.

In fact, this is a reported bug: https://bugs.php.net/bug.php?id=62337

Hope that helps! :)

- Trevor

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

[Niklas Keller]

2016-06-15 19:38 GMT+02:00 Fleshgrinder :

> On 6/15/2016 12:27 PM, 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 (Throwable $e) {
> > echo 'Catch!';
> > } finally {
> > echo 'Finally?';
> > }
> > // Warning: require(no.php): failed to open stream: No such file or
> > directory
> > // Fatal error: require(): Failed opening required 'no.php'
> >
>
> This is exactly how require is meant to work, just use include as
> Christoph said already. These are two distinct features for a reason.
>
> On 6/15/2016 12:27 PM, Alexander Lisachenko wrote:
> > Can we also add FileNotFoundException and use it for all file functions
> to
> > avoid silencing with "@" operator? Then require expression can throw an
> > Error with nested FileNotFoundException.
> >
>
> We definitely need this but it cannot go into PHP 7.0.


I think it can go into 7.1. It's not a BC break, as it will still produce a
fatal error if the error isn't caught.


>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Fleshgrinder]

On 6/15/2016 1:38 PM, Jordi Boggiano wrote:
> We are finally seeing more rapid PHP version adoption and I think it
> would be a shame to break the trust PHP gained in the last few years of
> stable and predictable releases.
> 

Well spoken Sir! :)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Fleshgrinder]

On 6/15/2016 1:30 AM, Tom Worster wrote:
> On 6/14/16 3:12 PM, Fleshgrinder wrote:
> 
>> Call me ignorant but is this required in typical web applications?
> 
> PHP is used for various things, not just web apps. I use it for various
> other things because its the language in which I am most fluent.
> 

> PHP is and should remain: a pragmatic web-focused language
>
> --- Rasmus Lerdorf

Please do not ignore our mission statement here. PHP is not a general
purpose language and even real general purpose languages do not offer
predictable RNGs.

On 6/15/2016 1:30 AM, Tom Worster wrote:
> And the requirements of *typical* apps using PHP should not be the basis
> for removing functions that are in fact used in existing programs.
> 

Moving to PECL is not considered a BC and people are easily able to get
the functions back in if they really need to.

On 6/15/2016 1:30 AM, Tom Worster wrote:
> It's possible to change programs so they don't use mt_rand() etc. but
> most people won't thank you for forcing them to rewrite software that
> works.
> 

The applications and libraries who are using it incorrectly right now
will thank us for making it harder to use the language incorrectly.

On 6/15/2016 1:30 AM, Tom Worster wrote:
> Leigh, iiuc, is trying to fix bugs. Let's not change the discussion to
> cleaning up PHP's API.
> 

This is not what my proposal is about. I would move all the broken and
weak stuff to PECL and offer the already existing good alternatives to
the developers. At the same time we are able to fix the problems in the
PECL modules and release a new major version of those packages.

We do not need to fix password_hash() nor random_int() since they work
and they are what is needed in a web-focused language.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Fleshgrinder]

On 6/15/2016 7:52 PM, Niklas Keller wrote:
> I think it can go into 7.1. It's not a BC break, as it will still produce a
> fatal error if the error isn't caught.
> 

file_get_contents() and friends emit an E_WARNING and not an E_ERROR or
worse. ;)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Niklas Keller]

Oh, just read the require example, didn't read it was planned for all file
functions.

Fleshgrinder  schrieb am Mi., 15. Juni 2016, 19:57:

> On 6/15/2016 7:52 PM, Niklas Keller wrote:
> > I think it can go into 7.1. It's not a BC break, as it will still
> produce a
> > fatal error if the error isn't caught.
> >
>
> file_get_contents() and friends emit an E_WARNING and not an E_ERROR or
> worse. ;)
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

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

[Niklas Keller]

Fleshgrinder  schrieb am Mi., 15. Juni 2016, 19:55:

> On 6/15/2016 1:30 AM, Tom Worster wrote:
> > On 6/14/16 3:12 PM, Fleshgrinder wrote:
> >
> >> Call me ignorant but is this required in typical web applications?
> >
> > PHP is used for various things, not just web apps. I use it for various
> > other things because its the language in which I am most fluent.
> >
>
> > PHP is and should remain: a pragmatic web-focused language
> >
> > --- Rasmus Lerdorf
>
> Please do not ignore our mission statement here. PHP is not a general
> purpose language and even real general purpose languages do not offer
> predictable RNGs.
>

Quoting from PHP.net:

PHP is a popular general-purpose scripting language that is especially
suited to web development.

On 6/15/2016 1:30 AM, Tom Worster wrote:
> > And the requirements of *typical* apps using PHP should not be the basis
> > for removing functions that are in fact used in existing programs.
> >
>
> Moving to PECL is not considered a BC and people are easily able to get
> the functions back in if they really need to.
>
> On 6/15/2016 1:30 AM, Tom Worster wrote:
> > It's possible to change programs so they don't use mt_rand() etc. but
> > most people won't thank you for forcing them to rewrite software that
> > works.
> >
>
> The applications and libraries who are using it incorrectly right now
> will thank us for making it harder to use the language incorrectly.
>
> On 6/15/2016 1:30 AM, Tom Worster wrote:
> > Leigh, iiuc, is trying to fix bugs. Let's not change the discussion to
> > cleaning up PHP's API.
> >
>
> This is not what my proposal is about. I would move all the broken and
> weak stuff to PECL and offer the already existing good alternatives to
> the developers. At the same time we are able to fix the problems in the
> PECL modules and release a new major version of those packages.
>
> We do not need to fix password_hash() nor random_int() since they work
> and they are what is needed in a web-focused language.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

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

[Fleshgrinder]

On 6/15/2016 9:31 PM, Niklas Keller wrote:
> Quoting from PHP.net:
> 
> PHP is a popular general-purpose scripting language that is especially
> suited to web development.
> 

Quoting from Wikipedia:

> PHP is a server-side scripting language designed for web development >
but also used as a general-purpose programming language.

But let use stop that now. I already wrote that someone should come up
with use cases for predictable random numbers other than creating
insecure secrets. This is the main problem that needs solving, people
using this stuff without knowing what they do.

Keep in mind that anyone or anything (company) that requires predictable
random numbers for their software (e.g. game) wants to have more control
over distribution and ways to tweak it. Hence, they will directly
implement it straight on their own anyways. Business rules are more
important in such domains than readily available built-in stuff.
Otherwise many people would not have jobs. :P

If they really don't want to they can still fall back to PECL. I really
do not see the shared hosting as a big argument here because shared
hosting directly falls back to web application and -- as I said before
-- in this context the requirement for predictable random numbers is
pretty much nil.

Just proof me wrong and show me where it is needed.

Drupal? Symfony? Zend? Wordpress? PhpBB? ...?

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Deprecations PHP 7.1

[Fleshgrinder]

What's the status here?

https://wiki.php.net/rfc/deprecations_php_7_1

I do not have the thread in my history anymore so cannot reply directly
to the actual thread.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Deprecations PHP 7.1

[Dmitry Stogov]

Nikita,


As I remember , you also liked to deprecate $errcontext argument of error 
handlers.


http://php.net/manual/en/function.set-error-handler.php


Thanks. Dmitry.


From: Fleshgrinder 
Sent: Wednesday, June 15, 2016 10:58:30 PM
To: php-internals; Nikita Popov
Subject: [PHP-DEV] Deprecations PHP 7.1

What's the status here?

https://wiki.php.net/rfc/deprecations_php_7_1

I do not have the thread in my history anymore so cannot reply directly
to the actual thread.

--
Richard "Fleshgrinder" Fussenegger

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

[Pascal MARTIN, AFUP]

Le 06/06/2016 09:22, Dmitry Stogov a écrit :

You can find the full RFC at: https://wiki.php.net/rfc/too_few_args

I encourage everyone to read the RFC and cast your vote towards whichever
option you feel is the best for the language and the community.


Hi,

At AFUP, we would be -1 for this RFC for PHP 7.1, as it causes a 
bc-break without bringing much (speaking about "features") in return.


Yes, it highlights (brightly) a situation in which there is probably a 
bug; but we think it changes behavior quite too brutally for a minor 
version.


On the other hand, we would be +1 for this in PHP 8.0, as this would 
help detect/catch bugs and it is "more OK" to break BC in a major version.


(I realize I'm basically repeating what others said in this very thread 
and/or in the one about bc-breaks in minor versions, but I'm posting 
anyway: one additional opinion cannot hurt, I hope)


In any case, thanks for your work on this!

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP allocating too much memory

[Peter LeBrun]

Hey everyone, thanks for your help and input.  We've narrowed it down to
cases where there is string concatenation with a constant, but currently
upgrading to 7.0.7 to see if that makes a difference.

Enjoy your evening,

Peter

On Wed, Jun 15, 2016 at 1:50 PM, Trevor Suarez  wrote:

> On Wed, Jun 15, 2016 at 11:34 AM, Michael Felt  wrote:
>
> >
> >
> > On 15-Jun-16 15:55, Rowan Collins wrote:
> >
> >> On 15/06/2016 14:01, Peter LeBrun wrote:
> >>
> >>> The weirdest part about this is that PHP is somehow trying to allocate
> >>> 140TB of memory.
> >>>
> >>
> >> I've seen numbers like that a few times - always around 140TB, but the
> >> exact number varies. I assume it's an overflow (or underflow?)
> somewhere,
> >> but the exact mechanism escapes me. (It's close to 2^47, but not very
> >> close; I've got examples logged as "low" as 140090229815192, and I think
> >> I've seen under 140 trillion.)
> >>
> > In hex: 7F694C627798 - so apparently 7F694 is common to
> > all.
> > FYI: I have seen similar issues with mixed environments (32 and 64-bit) -
> > at this point I am surprised that you can even dlopen() both sizes (my OS
> > now refuses to dlopen() 32-bit modules aka shared libraries when 64-bit
> > application and v.v.)
> >
> >> Apart from sheer curiosity of where this magic number comes from, I
> >> wonder if there is some sanity check missing in the memory manager to at
> >> least display a different error message...
> >>
> >> Regards,
> >>
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> I've seen this bug come up with the SOAP extension. I saw it happen when
> instantiating a SoapClient or SoapServer when the constructor tries to load
> a WSDL file under very certain circumstances. If the SOAP WSDL caching is
> on (if `soap.wsdl_cache = 1`), the WSDL file is cached (or is attempting to
> be cached) or the WSDL must be downloaded, and the file-system is full,
> then this crazy overflow can happen. I believe it's due to the WSDL's
> becoming corrupted due to the file-system halting the write of the file and
> PHP not cleaning up the improper write.
>
> In fact, this is a reported bug: https://bugs.php.net/bug.php?id=62337
>
> Hope that helps! :)
>
> - Trevor
>

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

[Pierre Joye]

On Jun 16, 2016 2:43 AM, "Fleshgrinder"  wrote:
>
> On 6/15/2016 9:31 PM, Niklas Keller wrote:
> > Quoting from PHP.net:
> >
> > PHP is a popular general-purpose scripting language that is especially
> > suited to web development.
> >
>
> Quoting from Wikipedia:
>
> > PHP is a server-side scripting language designed for web development >
> but also used as a general-purpose programming language.
>
> But let use stop that now. I already wrote that someone should come up
> with use cases for predictable random numbers other than creating
> insecure secrets. This is the main problem that needs solving, people
> using this stuff without knowing what they do.
>
> Keep in mind that anyone or anything (company) that requires predictable
> random numbers for their software (e.g. game) wants to have more control
> over distribution and ways to tweak it. Hence, they will directly
> implement it straight on their own anyways.

No they don't all do it.

There are ways to achieve what you want in a nice way while not breaking
things. Let consider them.

Cheers,
Pierre

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

[Pierre Joye]

Hi,
On Jun 6, 2016 2:22 PM, "Dmitry Stogov"  wrote:
>
> Hi,
>
>
> 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 your vote towards whichever
> option you feel is the best for the language and the community.

I voted no for bc reasons.

I do think it is a relatively small thing but still bc.

The other point that makes me vote no is the short discussion period. The
rule is a minimum discussion time, not a "let choose randomly depending on
what or who". This is worrisome.

My take on it is that the RMs should veto it  (it is part of their roles).

Thanks
Pierre

Re: [PHP-DEV] PHP allocating too much memory

[Pierre Joye]

Hi

On Jun 16, 2016 7:22 AM, "Peter LeBrun"  wrote:
>
> Hey everyone, thanks for your help and input.  We've narrowed it down to
> cases where there is string concatenation with a constant, but currently
> upgrading to 7.0.7 to see if that makes a difference.

Is it possible to open a bug or post a reproduce script here please?

> Enjoy your evening,
>
> Peter
>
> On Wed, Jun 15, 2016 at 1:50 PM, Trevor Suarez  wrote:
>
> > On Wed, Jun 15, 2016 at 11:34 AM, Michael Felt 
wrote:
> >
> > >
> > >
> > > On 15-Jun-16 15:55, Rowan Collins wrote:
> > >
> > >> On 15/06/2016 14:01, Peter LeBrun wrote:
> > >>
> > >>> The weirdest part about this is that PHP is somehow trying to
allocate
> > >>> 140TB of memory.
> > >>>
> > >>
> > >> I've seen numbers like that a few times - always around 140TB, but
the
> > >> exact number varies. I assume it's an overflow (or underflow?)
> > somewhere,
> > >> but the exact mechanism escapes me. (It's close to 2^47, but not very
> > >> close; I've got examples logged as "low" as 140090229815192, and I
think
> > >> I've seen under 140 trillion.)
> > >>
> > > In hex: 7F694C627798 - so apparently 7F694 is common
to
> > > all.
> > > FYI: I have seen similar issues with mixed environments (32 and
64-bit) -
> > > at this point I am surprised that you can even dlopen() both sizes
(my OS
> > > now refuses to dlopen() 32-bit modules aka shared libraries when
64-bit
> > > application and v.v.)
> > >
> > >> Apart from sheer curiosity of where this magic number comes from, I
> > >> wonder if there is some sanity check missing in the memory manager
to at
> > >> least display a different error message...
> > >>
> > >> Regards,
> > >>
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> > I've seen this bug come up with the SOAP extension. I saw it happen when
> > instantiating a SoapClient or SoapServer when the constructor tries to
load
> > a WSDL file under very certain circumstances. If the SOAP WSDL caching
is
> > on (if `soap.wsdl_cache = 1`), the WSDL file is cached (or is
attempting to
> > be cached) or the WSDL must be downloaded, and the file-system is full,
> > then this crazy overflow can happen. I believe it's due to the WSDL's
> > becoming corrupted due to the file-system halting the write of the file
and
> > PHP not cleaning up the improper write.
> >
> > In fact, this is a reported bug: https://bugs.php.net/bug.php?id=62337
> >
> > Hope that helps! :)
> >
> > - Trevor
> >

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Joe Watkins]

Morning,

   > This would keep the "BC promise" intact instead of going back to
cowboy php days.

   > Please don't let's make it harder to go from 7.0 to 7.1 than it was
from 5.6 to 7.0.

   Can we reduce hyperbole to nil, please.

   Before work starts on PHP 8, we need to have something worth branching,
just as we needed for 7, and 6.

   There is no sense in which the too_few_args vote was unfair, biased, or
anything comparable to "the old days" (it wasn't committed without public
consultation).

   The majority have decided that the *extremely minor* BC break is worth
the tradeoff.

Cheers
Joe


On Wed, Jun 15, 2016 at 5:10 PM, Rowan Collins 
wrote:

> On 15/06/2016 12:38, Jordi Boggiano wrote:
>
>> On 15/06/2016 11:41, Pierre Joye wrote:
>>
>>> I also understand the needs to change, update, optimize or clean our
>>> edge cases to open the path to JIT and the likes. However I would be
>>> very careful about that, and Dmitry and the team are very careful. I
>>> also have to say that to the very short timeline to finalize 7.0
>>> should not be paid by breaking BCs in 7.x. We can have a short
>>> timeline for 8.0 as well. If we need more drastic BC breaks earlier
>>> than expected. If JIT is a goal for 8.0, then let do the BC breaks in
>>> 8.0 and prepare our users using 7.x.
>>>
>>
>> +1 to that, it would be much better to introduce BC (strong/er) warnings
>> in 7.1/7.2 and then if needed branch off 8.0 already so that JIT work
>> can happen there with the BC warnings (and related features) removed.
>> 8.0 could then come a year or two after 7.1 depending on how the JIT
>> work progresses.
>>
>
> Dmitry, Stas, do you think something like this could work? Could we have a
> "php.next" preview branch with lots of performance work going on,
> especially if a lot of it is focused around opcache anyway?
>
> - You could still raise RFCs for expected breaking changes, to make sure
> you have approval for a language change before investing time depending on
> it, but set their target as 8.0.
> - Users would know what to expect from each release, and have plenty of
> notice to make their code "php8-ready".
> - Even if we're not ready to turn on JIT, an accumulation of improvements
> would give users a more visible incentive to handle any compatibility
> problems.
> - Grander plans that don't happen to be ready at the same time can always
> go into 9.0 instead.
>
>
> This would keep the "BC promise" intact instead of
>> going back to cowboy php days.
>>
>
> This. A hundred times this. Please don't let's make it harder to go from
> 7.0 to 7.1 than it was from 5.6 to 7.0.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Dmitry Stogov]

Hi internals,


The RFC https://wiki.php.net/rfc/this_var was accepted by 43 against 0, and the 
corresponding patch was merged into master.


Thanks. Dmitry.

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

[Dmitry Stogov]

Hi internals,


The RFC https://wiki.php.net/rfc/too_few_args was 
accepted by 39 against 11, and the corresponding patch was merged into master.


Thanks. Dmitry.

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

[Pierre Joye]

Hi Dmitry

I am sorry but I have to ask to wait before merging it.

It is definitely not clear that:

. The rfc was valid to begin with due to the short discussion time
. This BC is acceptable for 7.x

I think things like things can be prevented by following the relatively
simple rfc process and having a more clear way to define what is acceptable
as BC.

I think the RMs should step in here.

Thanks,
Pierre
On Jun 16, 2016 1:12 PM, "Dmitry Stogov"  wrote:

> Hi internals,
>
>
> The RFC https://wiki.php.net/rfc/too_few_args
> was accepted by 39 against 11, and the corresponding patch was merged into
> master.
>
>
> Thanks. Dmitry.
>
>

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Pierre Joye]

On Jun 16, 2016 11:41 AM, "Joe Watkins"  wrote:
>
> Morning,
>
>> This would keep the "BC promise" intact instead of going back to
> cowboy php days.
>
>> Please don't let's make it harder to go from 7.0 to 7.1 than it was
> from 5.6 to 7.0.
>
>Can we reduce hyperbole to nil, please.
>
>Before work starts on PHP 8, we need to have something worth branching,
> just as we needed for 7, and 6.
>
>There is no sense in which the too_few_args vote was unfair, biased, or
> anything comparable to "the old days" (it wasn't committed without public
> consultation).
>
>The majority have decided that the *extremely minor* BC break is worth
> the tradeoff.

We have cases where our view on a problem and its impact was wrong, totally
wrong.

The rfc process allows veto even if accepted. I am very worried about how
things were done here. See my reply to Dmitry's approval mail for the
reasons.

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

[Dmitry Stogov]

Hi Pierre,


On 06/16/2016 09:18 AM, Pierre Joye wrote:


Hi Dmitry

I am sorry but I have to ask to wait before merging it.



Sorry, but this is already merged.


It is definitely not clear that:

. The rfc was valid to begin with due to the short discussion time
. This BC is acceptable for 7.x

I think things like things can be prevented by following the 
relatively simple rfc process and having a more clear way to define 
what is acceptable as BC.




I think, the decision of the majority of voters, told that the BC break 
is minor and acceptable for 7.1.

The only mistake was in shorten discussion period.


I think the RMs should step in here.



Yeah, I suppose, RMs may have a right to take a decision and revert this.

Thanks. Dmitry.


Thanks,
Pierre

On Jun 16, 2016 1:12 PM, "Dmitry Stogov" > wrote:


Hi internals,


The RFC
https://wiki.php.net/rfc/too_few_args
was accepted by 39 against 11, and the corresponding patch was
merged into master.


Thanks. Dmitry.

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

[Dmitry Stogov]

The voting dates was changed to Jun 24 (to satisfy 2 weeks discussion period).


In my opinion the BC break is minimal.

Actually, the "wrong" behavior was reported by 
https://bugs.php.net/bug.php?id=71127

Before this, opcache worked "improperly" for few years (at least since php-5.4).

Unfortunately, we fixed https://bugs.php.net/bug.php?id=71127 too later and 
weren't able to fix PHP-7.0 "properly".


Now I propose a safer and more consistent way of handling attempts of constants 
redefinition.

RFC also proposes a way to "fix" affected applications, wrapping constant 
definitions, that may be redefined, with try/catch.


Thanks. Dmitry.


From: Dmitry Stogov
Sent: Friday, June 10, 2016 11:06:55 PM
To: PHP internals
Subject: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition


Hi internals,


Please review: https://wiki.php.net/rfc/constant_redefinition


Thanks. Dmitry.