Re: [PHP-DEV] Suggestion Method Constant

[Sara Golemon]

On Thu, Oct 12, 2017 at 2:33 PM, Michael Döhler  wrote:
> I am open for any approach, but maybe we have to differentiate between class 
> constants and method references?
>
Given the discussion we had around the namespace separator (and why we
DIDN'T go with ::), there may be similar issues here.  Maybe not,
given the final component is specifically T_METHOD, but it should be
prototyped to be sure.

As to what such a reference would evaluate to:   Foo::bar::method -> [
Foo::class, 'bar' ] as Michael Döhler suggests seems the obvious
answer, but (Foo::class.'::bar') may be what some would expect.
Ideally we'd have first-class references to functions.

-Sara

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

Re: [PHP-DEV] Suggestion Method Constant

[Michael Döhler]

Hi,

I am open for any approach, but maybe we have to differentiate between class 
constants and method references? 

Michael 

> Am 12.10.2017 um 20:28 schrieb Mathias Grimm :
> 
> The only problem with the @ symbol is the lack of consistency with the other 
> constants class constants are also MyClass::MY_CONST, or MyClass::class, so I 
> think it makes sense to also be MyClass::myMethod::method
> 
>> On 12 October 2017 at 20:24, Michael Döhler  wrote:
>> Hi,
>> 
>> Same i have in mind, for example: MyClass@myMethod
>> 
>> To make also some method call routing easier, e.g. in userland routers.
>> 
>> Transform the current approach:
>> 
>> $app->get("/foo", [MyClass::class, "myMethod"]);
>> 
>> To:
>> 
>> $app->get("/foo", MyClass@myMethod);
>> 
>> This will ease a lot, e.g. for refactoring, IDE usage and completes the code 
>> as configuration approach for PHP.
>> 
>> Thanks
>> Michael
>> 
>> > Am 12.10.2017 um 19:43 schrieb Mathias Grimm :
>> >
>> > I would like to suggest a method constant that could be used the same way
>> > we use the ::class one
>> >
>> > I don't have a strong personal preference but it could be something like:
>> >
>> > MyController::myActionMethod::method, no sure about the internals but it
>> > would be consistent with the one for the class.
>> >
>> > Cheers,
> 

Re: [PHP-DEV] Suggestion Method Constant

[Michael Döhler]

Hi,

Same i have in mind, for example: MyClass@myMethod

To make also some method call routing easier, e.g. in userland routers.

Transform the current approach:

$app->get("/foo", [MyClass::class, "myMethod"]);

To:

$app->get("/foo", MyClass@myMethod);

This will ease a lot, e.g. for refactoring, IDE usage and completes the code as 
configuration approach for PHP.

Thanks
Michael

> Am 12.10.2017 um 19:43 schrieb Mathias Grimm :
> 
> I would like to suggest a method constant that could be used the same way
> we use the ::class one
> 
> I don't have a strong personal preference but it could be something like:
> 
> MyController::myActionMethod::method, no sure about the internals but it
> would be consistent with the one for the class.
> 
> Cheers,

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

Re: [PHP-DEV] Suggestion Method Constant

[Mathias Grimm]

The only problem with the @ symbol is the lack of consistency with the
other constants class constants are also MyClass::MY_CONST, or
MyClass::class, so I think it makes sense to also be
MyClass::myMethod::method

On 12 October 2017 at 20:24, Michael Döhler  wrote:

> Hi,
>
> Same i have in mind, for example: MyClass@myMethod
>
> To make also some method call routing easier, e.g. in userland routers.
>
> Transform the current approach:
>
> $app->get("/foo", [MyClass::class, "myMethod"]);
>
> To:
>
> $app->get("/foo", MyClass@myMethod);
>
> This will ease a lot, e.g. for refactoring, IDE usage and completes the
> code as configuration approach for PHP.
>
> Thanks
> Michael
>
> > Am 12.10.2017 um 19:43 schrieb Mathias Grimm :
> >
> > I would like to suggest a method constant that could be used the same way
> > we use the ::class one
> >
> > I don't have a strong personal preference but it could be something like:
> >
> > MyController::myActionMethod::method, no sure about the internals but it
> > would be consistent with the one for the class.
> >
> > Cheers,
>

[PHP-DEV] Suggestion Method Constant

[Mathias Grimm]

I would like to suggest a method constant that could be used the same way
we use the ::class one

I don't have a strong personal preference but it could be something like:

MyController::myActionMethod::method, no sure about the internals but it
would be consistent with the one for the class.

Cheers,

[PHP-DEV] Enchant 2

[Christoph M. Becker]

Hi!

I've noticed the other day that Enchant 2.0.0 has been released in
August[1].  ext/enchant does not support Enchant 2 yet, however.  Only a
few fixes are necessary to make it compile[2], but there is an issue
regarding the PHP functions enchant_broker_set_dict_path() and
enchant_broker_get_dict_path(), which rely on enchant_broker_get_param()
which has been completely removed.  Instead there is now a single
function to specify the path where to look for the dictionary files:
enchant_set_prefix_dir()[3].  Apparently, it would be possible to store
the individual paths internally, and to call enchant_set_prefix_dir()
whenever a dictionary is requested or checked for existence, thus
retaining the old functionality.

I have some doubts if this would be sensible, though, because
enchant_broker_(s|g)et_dict_path() only supported the Ispell and
Myspell/Hunspell back-ends anyway.  Instead it may be more reasonable to
introduce a new PHP function enchant_set_prefix_dir() which would
directly map to the C function with the same name.  Depending on whether
ext/enchant had been compiled with Enchant 1 and 2, respectively, the
other function(s) would not be available.  If done this way, the
constants PHP_ENCHANT_MYSPELL and PHP_ENCHANT_ISPELL should neither be
available, if compiled with Enchant 2, because they are only useful for
enchant_broker_(s|g)et_dict_path().

Somewhat related to supporting Enchant 2 would be the question if we can
lift the requirements to Enchant 1.6.0 (released 2010-04-01).  This
version introduced enchant_get_version() (which is still there in
Enchant 2), and would allow us to simplify and clean the libenchant
version info in PHP info[4].

Thoughts?  Would that require an RFC?

[1] 
[2] 
[3] 
[4]


-- 
Christoph M. Becker

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

Re: [PHP-DEV] Mysql result data types

[li...@rhsoft.net]

Am 12.10.2017 um 17:16 schrieb Johannes Schlüter:

On Do, 2017-10-12 at 14:55 +0300, Reinis Rozitis wrote:

Hello,
is there a reason (technical or historical) why the data coming from
MySQL is always strings?
I've found only one case where the data type is "honored" -
PDO+mysqlnd+emulation off [1]


The reason for this is that this is the way the protocol works. With
non-prepared statements the server sends the data in textual form. With
prepared statements it switches to a different protocol sending values
in binary form.
There was a proposal in the server once that would use binary also for
non-prepared statements, but was rejected, for reasons i don't recall.
(maybe backwards compatibility)
MySQL's new X protocol uses binary representation by defalt, but is no
drop in replacment, but new protocol, with new clients etc


as i understand that below MYSQLI_OPT_INT_AND_FLOAT_NATIVE does not 
convert but *return* native types and benchamrks support this


http://blog.ulf-wendel.de/2008/php-new-network-traffic-cpu-and-memory-savings-with-mysqlnd/

A new mysqlnd only option gives you 3). Try out mysqli_options($link, 
MYSQLI_OPT_INT_AND_FLOAT_NATIVE, true)




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

[PHP-DEV] Re: Fix for unserialise() "vulnerabilities"

[Dmitry Stogov]

On Oct 12, 2017 6:01 PM, Nikita Popov  wrote:
On Thu, Oct 12, 2017 at 4:38 PM, Dmitry Stogov 
> wrote:

Hi,


I've found, that at least half of unserialise() security problems, occurs 
because of non-symmetric serialize/unserialize assumption, regarding references 
encoded with "r".


serialize() assumes it's an object.


https://github.com/php/php-src/blob/master/ext/standard/var.c#L828


universalize() allows any value.


https://github.com/php/php-src/blob/master/ext/standard/var_unserializer.re#L677


This allows manual crafting of strings that may lead to creation of unexpected 
data structures.

I propose to fix this just by fixing the symmetry.


https://gist.github.com/dstogov/53382540bdfee7b6c7dadf142dc437ed


This will prohibit, some manually crafted strings.

Of course, this will break few "security" related tests. Especially:


> Bug #70284 (Use after free vulnerability in unserialize() with GMP) 
> [ext/gmp/tests/bug70284.phpt]
> Bug #70211 (php 7 ZEND_HASH_IF_FULL_DO_RESIZE use after free) 
> [ext/soap/tests/bug70211.phpt]
> Bug #70172 - Use After Free Vulnerability in unserialize() 
> [ext/standard/tests/serialize/bug70172.phpt]
> Bug #70963 (Unserialize shows UNKNOW in result) 
> [ext/standard/tests/serialize/bug70963.phpt]
> Memleaks if unserialize return a self-referenced array/object 
> [ext/standard/tests/serialize/unserialize_mem_leak.phpt]
> Bug #72433: Use After Free Vulnerability in PHP's GC algorithm and 
> unserialize [ext/standard/tests/strings/bug72433.phpt]

Any objections? (this is for master only of course)

Hi,

I don't think this will really fix any vulnerabilities, because the core issue 
are R references, not r references. If this prevents a vulnerability using r, 
you can usually replicate something similar using R instead.

However, I still agree that it makes sense to restrict this. Especially because 
unserialize() currently allows creating structures that are just impossible in 
plain PHP, such as cyclic arrays without use of references (GLOBALS 
notwithstanding).

The check looks too strict to me though. Shouldn't it first DEREF the value 
before performing the OBJECT check? (E.g. for something like 
"a:3:{i:0;O:8:"stdClass":0:{}i:1;R:2;i:2;r:2;}", in which case r:2 will be a 
REF to OBJECT).

Thanks, for catching. You are right. I'll fix the patch a bit later. Just add 
DEREF.

Dmitry.


Regards,
Nikita

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

[Matteo Beccati]

Hi Dan,

On 12/10/2017 14:06, Dan Ackroyd wrote:
> If we add more magic methods to PDO, that are only present when the
> connection was made to an SQLite DB, then there will be more mess to
> cleanup, and more people are likely to complain about BC breaks,
> if/when we refactor the features to not have shitty magic behaviour.

Since no one is planning to do such refactoring anytime soon, I see no
reason to block any attempt to add driver-specific methods (i.e.
features that only belong to a specific driver) until further notice.
Whoever chooses to use them knows already their code is not portable to
other drivers anyway.

I have added a few PDO::pgsql* ones myself and feel no shame ;)


> People have suggested changing the RFC process to require 2/3 approval
> for all RFCs. This RFC is a prime example of why that might be needed.
> We shouldn't be approving changes that are just barely good enough to
> be included. Changes should be clearly the right choice, to be
> included.

I agree with the 2/3 boundary, but this specific RFC follows PDO's
current standards. The fact that they are suboptimal to me is out of scope.

Sill, I hope that proper LOB field type support lands in PDO_sqlite as
well soon after.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

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

Re: [PHP-DEV] Mysql result data types

[Johannes Schlüter]

On Do, 2017-10-12 at 14:55 +0300, Reinis Rozitis wrote:
> Hello,
> is there a reason (technical or historical) why the data coming from
> MySQL is always strings?
> I've found only one case where the data type is "honored" -
> PDO+mysqlnd+emulation off [1]

The reason for this is that this is the way the protocol works. With
non-prepared statements the server sends the data in textual form. With
prepared statements it switches to a different protocol sending values
in binary form.
There was a proposal in the server once that would use binary also for
non-prepared statements, but was rejected, for reasons i don't recall.
(maybe backwards compatibility)
MySQL's new X protocol uses binary representation by defalt, but is no
drop in replacment, but new protocol, with new clients etc.

> We made a fairly simple patch to 'mysqlnd' which enables
> (configurable via ini) data to be returned (trying to match) as
> defined in database/table. 
> 
> In general something like:
> 
> switch( field->type ){
>   case MYSQL_TYPE_TINY:
>   case MYSQL_TYPE_SHORT:
>   case MYSQL_TYPE_LONG:
>   case MYSQL_TYPE_LONGLONG:
>   case MYSQL_TYPE_INT24:
>   convert_to_long(data);
>   break;
>   case MYSQL_TYPE_DECIMAL:
>   case MYSQL_TYPE_DOUBLE:
>   case MYSQL_TYPE_FLOAT:
>   case MYSQL_TYPE_NEWDECIMAL:
>   convert_to_double(data);
>   break;
> }

It's not that trivial: With such a conversion the values might
overflow. What happens if the server returns an huge unsigned value
which PHP's signed integers can't represent? Does the type then change
based  on the specific value?
You're also converting a precise DECIMAL in an imprecise double which
will lose precision.
Also consider that many applications don't do extra calculations on
such returned data, but carry it through and then return as a string
(be it HTML, JSON; XML or whatever) thus have two "useless" conversions
(while carrying a tiny bit more memory around ...)
Traditional in PHP the string is no problem, as the engine will convert
when needed (and only then ...), I don't know how scalar typing in the
large view changed this ..but even in sch a code base here'd be a
conversion only for those who want it ...

> Does it make sense to create a PR and/or RFC for something like this?

If the community wants this, this could be done, I'm a bit skeptical
and I'd suggest to benchmark some systems passing lots of data around.

johannes

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

[PHP-DEV] Re: Fix for unserialise() "vulnerabilities"

[Nikita Popov]

On Thu, Oct 12, 2017 at 4:38 PM, Dmitry Stogov  wrote:

> Hi,
>
>
> I've found, that at least half of unserialise() security problems, occurs
> because of non-symmetric serialize/unserialize assumption, regarding
> references encoded with "r".
>
>
> serialize() assumes it's an object.
>
>
> https://github.com/php/php-src/blob/master/ext/standard/var.c#L828
>
>
> universalize() allows any value.
>
>
> https://github.com/php/php-src/blob/master/ext/standard/
> var_unserializer.re#L677
>
>
> This allows manual crafting of strings that may lead to creation of
> unexpected data structures.
>
> I propose to fix this just by fixing the symmetry.
>
>
> https://gist.github.com/dstogov/53382540bdfee7b6c7dadf142dc437ed
>
>
> This will prohibit, some manually crafted strings.
>
> Of course, this will break few "security" related tests. Especially:
>
>
> > Bug #70284 (Use after free vulnerability in unserialize() with GMP)
> [ext/gmp/tests/bug70284.phpt]
> > Bug #70211 (php 7 ZEND_HASH_IF_FULL_DO_RESIZE use after free)
> [ext/soap/tests/bug70211.phpt]
> > Bug #70172 - Use After Free Vulnerability in unserialize()
> [ext/standard/tests/serialize/bug70172.phpt]
> > Bug #70963 (Unserialize shows UNKNOW in result)
> [ext/standard/tests/serialize/bug70963.phpt]
> > Memleaks if unserialize return a self-referenced array/object
> [ext/standard/tests/serialize/unserialize_mem_leak.phpt]
> > Bug #72433: Use After Free Vulnerability in PHP's GC algorithm and
> unserialize [ext/standard/tests/strings/bug72433.phpt]
>
> Any objections? (this is for master only of course)
>

Hi,

I don't think this will really fix any vulnerabilities, because the core
issue are R references, not r references. If this prevents a vulnerability
using r, you can usually replicate something similar using R instead.

However, I still agree that it makes sense to restrict this. Especially
because unserialize() currently allows creating structures that are just
impossible in plain PHP, such as cyclic arrays without use of references
(GLOBALS notwithstanding).

The check looks too strict to me though. Shouldn't it first DEREF the value
before performing the OBJECT check? (E.g. for something like
"a:3:{i:0;O:8:"stdClass":0:{}i:1;R:2;i:2;r:2;}", in which case r:2 will be
a REF to OBJECT).

Regards,
Nikita

[PHP-DEV] Fix for unserialise() "vulnerabilities"

[Dmitry Stogov]

Hi,


I've found, that at least half of unserialise() security problems, occurs 
because of non-symmetric serialize/unserialize assumption, regarding references 
encoded with "r".


serialize() assumes it's an object.


https://github.com/php/php-src/blob/master/ext/standard/var.c#L828


universalize() allows any value.


https://github.com/php/php-src/blob/master/ext/standard/var_unserializer.re#L677


This allows manual crafting of strings that may lead to creation of unexpected 
data structures.

I propose to fix this just by fixing the symmetry.


https://gist.github.com/dstogov/53382540bdfee7b6c7dadf142dc437ed


This will prohibit, some manually crafted strings.

Of course, this will break few "security" related tests. Especially:


> Bug #70284 (Use after free vulnerability in unserialize() with GMP) 
> [ext/gmp/tests/bug70284.phpt]
> Bug #70211 (php 7 ZEND_HASH_IF_FULL_DO_RESIZE use after free) 
> [ext/soap/tests/bug70211.phpt]
> Bug #70172 - Use After Free Vulnerability in unserialize() 
> [ext/standard/tests/serialize/bug70172.phpt]
> Bug #70963 (Unserialize shows UNKNOW in result) 
> [ext/standard/tests/serialize/bug70963.phpt]
> Memleaks if unserialize return a self-referenced array/object 
> [ext/standard/tests/serialize/unserialize_mem_leak.phpt]
> Bug #72433: Use After Free Vulnerability in PHP's GC algorithm and 
> unserialize [ext/standard/tests/strings/bug72433.phpt]

Any objections? (this is for master only of course)


Thanks. Dmitry.

RE: [PHP-DEV] Mysql result data types

[Reinis Rozitis]

> who forces you to ext/mysql?

It's out of topic but obviously the code/software and products on the servers.

For me as a system administrator I have choice either to never upgrade (for 
example https://w3techs.com/technologies/details/pl-php/all/all one can see the 
rough rate of php version adoption) or work around the issues/lack of features 
in the deprecated stuff (or answer why I broke everything).

While I prefer bleeding edge it's not always an option (to force everyone) and 
in general 7.1+ext/mysql+mysqlnd works just fine.

rr


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

Re: [PHP-DEV] Mysql result data types

[li...@rhsoft.net]

Am 12.10.2017 um 14:34 schrieb Reinis Rozitis:

no idea what the state of PDO is


http://blog.ulf-wendel.de/2008/php-new-network-traffic-cpu-and-memory-
savings-with-mysqlnd/

if(mysqli_options($this->conn, MYSQLI_OPT_INT_AND_FLOAT_NATIVE,


Thanks,
as we still partly (forced to) live in the "deprecated or moved to pecl" 
ext/mysql world this gave the idea to actually implement the int_and_float_native into 
the extension rather than alter the driver (which apparently already has such 
functionality)


who forces you to ext/mysql?

don't get me wrong but we implemented 'mysqli' in our database layer a 
decade ago, at that time with 'enable_mysqli' which not so much later 
defaulted to be enabled that i don't see any code in 2017 which still 
did not cope as unmaintained and broken stuff


we stopped build PHP with ext/mysql 4 years ago at all

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

RE: [PHP-DEV] Mysql result data types

[Reinis Rozitis]

> no idea what the state of PDO is
> 
> 
> http://blog.ulf-wendel.de/2008/php-new-network-traffic-cpu-and-memory-
> savings-with-mysqlnd/
> 
>if(mysqli_options($this->conn, MYSQLI_OPT_INT_AND_FLOAT_NATIVE,

Thanks,
as we still partly (forced to) live in the "deprecated or moved to pecl" 
ext/mysql world this gave the idea to actually implement the 
int_and_float_native into the extension rather than alter the driver (which 
apparently already has such functionality).

rr


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

Re: [PHP-DEV] Session extension cannot be used in a loop/CLI since 7.2

[Björn Larsson]

Den 2017-10-09 kl. 13:20, skrev Nicolas Grekas:

Hello,

I'm having a hard time fixing Symfony's tests suite to 7.2 because of the
added warnings+ini_set-rejections in the Session module.

Testing the session on the CLI is not possible anymore without starting one
PHP process per test case. Why not, you may say.

BUT, this also means that the session module is now basically useless in a
request-response loop.
That means ReactPHP, PHP-PM, Amp & the likes are all going to have to
rewrite a userland session module completely. That also means e.g. Symfony
and all other frameworks will have to move away from the internal's Session
module if they want to work also with these long living processing model.

PHP is less "generic" now - with stronger bindings to its short lived
req/resp. cycle.
Is it something internal should care about? Should we reconsider this for
7.2?

Regards,
Nicolas


One aspect that comes to mind is if this has a negative impact
on the adaptation / uptake of 7.2 once it's released? Could be
valuable to have the RMs view on this changed behaviour.

r//Björn

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

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

[Dan Ackroyd]

On 12 October 2017 at 00:11, BohwaZ/PHP  wrote:

> I don't really understand that logic. Yeah the existing behaviour is not
> optimal. But there is no other solution right now.

"First, do no harm", "given an existing problem, it may be better not
to do something, or even to do nothing, than to risk causing more harm
than good."

If we add more magic methods to PDO, that are only present when the
connection was made to an SQLite DB, then there will be more mess to
cleanup, and more people are likely to complain about BC breaks,
if/when we refactor the features to not have shitty magic behaviour.

People have suggested changing the RFC process to require 2/3 approval
for all RFCs. This RFC is a prime example of why that might be needed.
We shouldn't be approving changes that are just barely good enough to
be included. Changes should be clearly the right choice, to be
included.


> It might be years (or never) before that PDO behaviour is changed. In the 
> meantime PHP will just be missing features that could have been provided, 
> this sounds strange to me.

openBlob has been available in the ext/sqlite3 extension for nine
years, apparently.

If it hasn't been present in PDO for all that time, and yet somehow
people have still managed to be able to use PHP, then it doesn't
exactly demonstrate that this is a feature that urgently needs to be
added, no matter how much extra mess it leaves.


> Should we also stop adding any feature to PHP because most
> PHP functions are named incoherently and we need to wait until
> all of them are renamed correctly? Hopefully not :)

You have a habit of taking people's opinions, and then trying to take
them to illogical conclusions, in order to try to win a discussion.

This seems to put you in the position of not even trying to understand
the other persons point of view, which is not helpful to you, if
you're trying to persuade people. It also makes me not want to
interact with you, as you're being deliberately obtuse.

cheers
Dan
Ack

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

Re: [PHP-DEV] Mysql result data types

[li...@rhsoft.net]

Am 12.10.2017 um 13:55 schrieb Reinis Rozitis:

is there a reason (technical or historical) why the data coming from MySQL is 
always strings?
I've found only one case where the data type is "honored" - 
PDO+mysqlnd+emulation off [1]


not entirely true, our database-layer acts directly with mysqli and 
unconditionally enables native types for the last 8 months or so after 
we mirgated our whole code to PHP7 native types


no idea what the state of PDO is


http://blog.ulf-wendel.de/2008/php-new-network-traffic-cpu-and-memory-savings-with-mysqlnd/

  if(mysqli_options($this->conn, MYSQLI_OPT_INT_AND_FLOAT_NATIVE, true) 
=== false)

  {
   $this->error('mysqli_options(MYSQLI_OPT_INT_AND_FLOAT_NATIVE) failed');
  }

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

[PHP-DEV] PHP 7.0.25RC1 is available for testing

[Anatol Belski]

Hi,

PHP 7.0.25 RC1 was just released and can be downloaded from:

 https://downloads.php.net/~ab/

The Windows binaries are available at

 http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your testing, please 
refer to the NEWS file:

 https://github.com/php/php-src/blob/php-7.0.25RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for October 26th, if no critical issues 
will be discovered in the RC.

Thank you for your support.

Regards,
 Anatol Belski and Ferenc Kovacs


P.S. Below is the verification information for the downloads.

php-7.0.25RC1.tar.bz2
SHA256 hash: 
4c885b1994089b4c5a9638a6a7e312ad67301a2816767035d785d99a05525810
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJZ3JOBAAoJELyqMOqcDVdjmxoIALOKuHfiQCM5aOP1zyWm7I9F
MtspAfKuJmsBL0kPdCtrCxpIQOHbykfRWYZsL2SjzeZig4RDvMRSaqk3JeKGaqbO
GCTzyMnmxDIBW4FCP19cj9tSNysL1BjkW+QweJ5gjZSSx/EfpOxVYebC7gP5y3HB
4sH5fT83niHo8rgJr5jPK7uPppIJNZKnzuXGmSVZjbiKs2eEhdMNs0sodkq+54gV
J7L4Gs6bt/Wfhr0XxPh4J3g2cPfWmX2NkYyiEAyMpiUz/JHW59sOm+UQwkIwT0YE
DB1dCvmxW1wqP3sYEEcPMJD+yoQqB7E5xKV1Mbj8EdNzF6bbGbd+EBC9pqO+vwQ=
=ENBH
-END PGP SIGNATURE-


php-7.0.25RC1.tar.gz
SHA256 hash: 
cf089950153cd6f9ac9e6144f3fb75d400ee6375e39713663555044e47aac6ac
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJZ3JOEAAoJELyqMOqcDVdjwCcIALjKpkzMQqzBTLPN6+uLAA4t
pyMc4bzbFZ07KKvWqwOiLeGGienNmeIX9/9ssBoOWG6rcONY5q6lqSfw4O9m9NG6
HSXe46eigtG90HW5dJLiD2WQX/aauTOF4NeZlM7I8Xkct4QItZ8cJmKFsowRM9pT
GW75LF0M57KO/Q2KLnMJpIsb87NgC5jdB6Xrd5aKS1/zsZFGUTyR2OxCPz0aar6k
etlxvAtoOov4BXsW7xopmA5wn18o+aFIVg60dK7XkbxgipUenJ+11w/x5xQxPuzY
+i5Tdzaf1S0eJgcfO3/QZAuz1WFTmV26/Dpdd7DHoNzsOsN2bEhZ/b5YrSjFxUw=
=uPpx
-END PGP SIGNATURE-


php-7.0.25RC1.tar.xz
SHA256 hash: 
4b42bdd262286c4fdc3f8794db6fa0b2e8e4475a4c1ecec4add9b17f4b81773b
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJZ3JOHAAoJELyqMOqcDVdjynkH/3uGBO77HdwsxXS3K6DV0Lws
KUnhir/xytK+TWLMzLI6mugSTeRsXBWM3Y4IqvC9clk2yWJuLpDn00tKpQJEaPtP
r8qtg1WD5nkz1vWEfDyUfGcEKr4TgUscjgHtA8ogLhBhi4EwL0chA0kciV/Pw/RW
YiEMiVuntyoZbWZDGRA+XkCTdFBMB87oejZ4L23jBjoNN8xjg2Y9+ZFm8kgeTMCk
A9tGx5HWh1SMCWEzr2BQYJUEWwZF9NCtm+mGhsERmTpFR3Y/kJTxWloOpsWX5S6O
wA6/PDz7aMjZq6KV4G61d35maBFovn0SDrdxQ/vi5y32Hsuf1exUDUQA6UBI7+g=
=maSx
-END PGP SIGNATURE-

[PHP-DEV] Mysql result data types

[Reinis Rozitis]

Hello,
is there a reason (technical or historical) why the data coming from MySQL is 
always strings?
I've found only one case where the data type is "honored" - 
PDO+mysqlnd+emulation off [1]

We made a fairly simple patch to 'mysqlnd' which enables (configurable via ini) 
data to be returned (trying to match) as defined in database/table. 

In general something like:

switch( field->type ){
case MYSQL_TYPE_TINY:
case MYSQL_TYPE_SHORT:
case MYSQL_TYPE_LONG:
case MYSQL_TYPE_LONGLONG:
case MYSQL_TYPE_INT24:
convert_to_long(data);
break;
case MYSQL_TYPE_DECIMAL:
case MYSQL_TYPE_DOUBLE:
case MYSQL_TYPE_FLOAT:
case MYSQL_TYPE_NEWDECIMAL:
convert_to_double(data);
break;
}

Does it make sense to create a PR and/or RFC for something like this?


[1] https://phpdelusions.net/pdo#returntypes


wbr
Reinis Rozitis


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

[PHP-DEV] PHP 7.2.0 RC4 released

[Remi Collet]

The fourth release candidate for 7.2.0 was just released and can be
downloaded from:

https://downloads.php.net/~remi/

Or using the git tag: php-7.2.0RC4

The Windows binaries are available at: http://windows.php.net/qa/

Please test it carefully, and report any bugs in the bug system.

The next release candidate will be tagged on Tuesday October 24th
and released on Thursday October 26th.

Hash Values and GPG signatures can be found below.

Thank you, and happy testing!


Sara
Remi



php-7.2.0RC4.tar.gz
SHA256 hash:
f89422d9bcd443e0f3d00d4be19f767dcbe4829efd561b5b9800fe0c57e16156
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJZ3KDIAAoJENyf+NPuWvJ/vWQQALJwpMqbGuRyyVywMT/xLQch
F11LQTmS1wuFm2oN5ojouTHFWqKF8MO/dD1CuRV16P5V8KJZmQaoM95Y23Rz2zu+
eFtxg8aai2wyDdGUiyT3jASwldVrNbO89UWAVark/jn42FXWkxyPITMnUkSW0Iiq
c3K2zQG1y+nlV8P/JokCtFNAq3WHaZGrXepkJeeRmTxc9XemR98fGcaGBAG7JFnv
uYoy25zGw8005WlMGh0qa2FSQ9LIdqr9Nmuk+959IgjDk1b6XwNI3adb4q1U1YMy
F+HWbEx1BW14jKOOPRv5YmjkBgNHn7jO2rXdaBaPV2yToXi9mXOyF4BN1eqqglEo
ZJjNVKha3BwHwk55fKolKynRDHPITJOsaj5G4x0Z3/qfoEMI/FNqhf1NkNAbYvw4
NPEAC9a5jLbsrxVbJ7xnYz/hFpbA6R6XoFWKm0Lw17lvwxJuya9Y4fe99GLL9ymi
IQqIyla2Ch6ed3k0rosPZH+iHui33QbCEe2/VO3YwsSYxZzovqw6F1QG/eyVqWuO
dJZVVLxlEn7mv6o9utv0CIf1ljERvaTCk5QlLvMWmo6zRDtVi2o8KFKekc+i8M5P
ld1EBZxGkxGc5oXjGsj338j2/zh61Id20JQEnQfoQPRfKOnWpdp3azamTwWMk9ZL
YE1GeGGuETFXR9P8aNyD
=SGNE
-END PGP SIGNATURE-

php-7.2.0RC4.tar.bz2
SHA256 hash:
81dba16f2a88cc19d1fac590af2a98b9029d7eee9c63b2d7cd18dde219d2b38a
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJZ3KDLAAoJENyf+NPuWvJ/jXQQAKP6mFs+G2ciX74+6qEIBDM5
1hWMmXhYSmEP0I5vE6cCtsVe/G/2b5w/fUkPRrQuPbCwIOx1joCtUKNLWS9uIF4n
t96+LtIeZuPmhtDvp+t+4cMb3reVxLtoHRnOV0EMxeqdW2SFRmzWRC84Je4vrEYH
GNruXQYw+NyRybGaPUTUybTzKYN390WufWQQxIruqg+hLcq4YyDV8sRcrPaawxys
vj78TsJu9r972yiQ9bub+y6o6q2ydSP4Huc5yEjEeenu9c/yWl9QVa/JT0sCylKV
Z2fsABq1kTc7Gsf5whmkWH//aBmQ5G5GHUYVOxT2+QrmG7a5SJkvPGqnEKNx3VI0
LFyJGKRtIVuPm9+vjeCVdIBl3uyxl1+w5woOg33eU3cj5oae6TXwdPEqBztGzyjz
TfPBtXL3czGwe3MzJEr7du+ASe+sUlNGJT64mK7mwH6g1BWOh1fg9fk/0k99UmmV
xXeNiOvu55T756Vky7P/yHapG3soETimel+9MEmWeoBY3uJv5h+zSI3XBZ68fAwN
UHc6QdBC3xJ5fYiZN2qq3T/rMFwQNp0yxqc1vJV6U1iBQrp9fl8HeqH1Owojurg5
RUYT7wYhXQ2qcbEe6b16dMjwJD4mSr1Ru+E5kxTaeOXvWDKPO/nuBCss5Sr7sSoR
bwRYUJJATg9goLBIYPAP
=ijYZ
-END PGP SIGNATURE-

php-7.2.0RC4.tar.xz
SHA256 hash:
08ee9e764891224d73f157e01594605fc85c63ffc9d4773d9ac29b0e3160c68f
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJZ3KDPAAoJENyf+NPuWvJ/ke4P/2iOcT/KwhEpWZJRcgXmROom
fgDmh0Z/SbYu/Exu3GLDrBVRQILVRqAusaDCwh7bznbmZXP41j+azssCqNBSO0Al
nrqFwjT4d1F9jInmFoGP+mpieNIwNky39IATUi8XexUfgIVaMsOQBCNucvjwtuuZ
z/hDHLJu8uKnbFPhNXQLH1AG452IeMfu6eneJZTPfigPq+U/kuIYhmURz7G0C4Yt
jh/lWdWwLFrLOghkDxYOVp3hsBw7MbCSLcGLUp55zQ0iQ4RTPLDNbLe3HIGZqYm7
6FN+pZ721zd7hYmnh0EHH1Us3qcPtofhYk1g+SdT0ZfwLO3RmzH7R4FP2D5yrOsB
KCNikCU0z35SN3renG2cyUqMZ2DyC6sfep4lvKpuS4LVEbgKk8bF5fRnyGO9pu4E
q29D8jvo7sjShrXdOvI1pzGfiXsPVJdkPQ96lxunUPO4+j965zoiSpFfxrzf3i2V
cpCvo+vOxFQgDcQXg9gSwRdfNoi/uQxi5s65/U5T/L4ff6bwrLPvqULomIXtFOaI
qso3Z4nvZLfgYQN5EvKmInA4QRmf8YlBkXVYMQIGUimLygeeC+Pj3wLDHKWyKX7B
cke/5rxZBt2Z8KYWuokiCHUmzX6E1YIEWbQm4aARYrcArbmc6Q9dMgJV1RrDVxgb
vahwo+2sfEJKf3EqQNNA
=CByJ
-END PGP SIGNATURE-

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

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

[Lester Caine]

On 12/10/17 00:11, BohwaZ/PHP wrote:
>> I think people were reasonably clear during the discussion.
>>
>> Having certain methods only available on an object depending on how it
>> was initialized is just not a good idea.
> 
> As far as I know, no one volunteered to rewrite PDO to change that?
> 
> I don't really understand that logic. Yeah the existing behaviour is not
> optimal. But there is no other solution right now.
> 
> Should we also stop adding any feature to PHP because most PHP functions
> are named incoherently and we need to wait until all of them are renamed
> correctly? Hopefully not :)
> 
> It might be years (or never) before that PDO behaviour is changed. In
> the meantime PHP will just be missing features that could have been
> provided, this sounds strange to me.

The 'other solution' right now is to ensure that the generic drivers for
each database API do the right thing, and if you must use generic
features then use those drivers. PDO SHOULD only provide the lowest
common denominator of data abstraction that works CLEANLY independent of
the driver selected. That has already been messed up by some of the
'extras' added to individual drivers and it is about time the ground
rules were clearly defined and enforced. That nobody has stepped up to
finish the parts of PDO that were put on the back burner when it was
prematurely pushed into the core build is perhaps a further indication
that it was not the right base from the start?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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