Re: [PHP-DEV] Getting SG(request_info).post_data/raw_post_data on master branch?
Hi Yasuo! On 17 September 2013 21:17, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, SG(request_info).post_data/raw_post_data is removed and modules supposed to read it from stream on master. Did the suggestion from UPGRADING.INTERNALS to use the php://input wrapper work out for you? Maybe I should add a comment inline... -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keywords as identifiers
missing any real-world examples of why it might be useful
One thing the I have run across in making my libraries, is the not being
able to call a function `default`.
I use the chainable getter/setter in one syntax a lot (a la jQuery). Hence
when I have a class with a property named default, and can not make a
method in that sense. It makes my API inconsistent as I have to use a
getDefault, setDefault, when every other method is a single word.
Such as:
class Foo {
public $default;
public function default($default = null) {
if ($default === null) {
return $this-default;
}
$this-default = $default;
return $this;
}
}
This might not be the prefered way to write methods, but I don't see why
the language should restrict me from doing so because the word default is
used in a different context.
On Wed, Sep 18, 2013 at 5:19 PM, Matthew Leverton lever...@gmail.comwrote:
On Tue, Sep 17, 2013 at 7:50 PM, Stuart Langley slang...@google.com
wrote:
To be honest, looking at the example in the RFC, being able to define a
member function 'new' on a class that completely changes the semantics of
the new operator is a great example of why you would not want this
feature.
It doesn't change anything because $foo-new() has no intrinsic
meaning in PHP. And I don't think the argument the programmer might
do something stupid ever holds much weight as a no vote against
anything. If somebody wants to create a confusing misnomer, he doesn't
need this proposed feature to do so.
But I agree that the RFC is missing any real-world examples of why it
might be useful, and that any new language feature should have
real-world benefits. Hopefully some more compelling reasons will be
added to the RFC.
Here's something that I've personally done with much shame:
class Where
{
private function _or($lhs, $op = null, $rhs = null)
{
}
public function __call($func_name, $args)
{
if ($func_name == 'or')
return call_user_func_array([$this, '_or'], $args);
}
}
$query-where('foo', '=', 1)-or('bar', '=', 2);
Imagine that $query-where() returns a Where object. I really want an
or method because it make things concise readable, but this is not
allowed. So I override the __call method to add such functionality,
which adds useless overhead.
There are a few keywords, such as list and unset, that I often wish I
could use in PHP. So in terms of readability, I think any sane
programmer would use this proposed functionality for good...
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keywords as identifiers
*Should have been !== null
On Wed, Sep 18, 2013 at 7:27 PM, David Neilsen da...@pan.co.nz wrote:
missing any real-world examples of why it might be useful
One thing the I have run across in making my libraries, is the not being
able to call a function `default`.
I use the chainable getter/setter in one syntax a lot (a la jQuery). Hence
when I have a class with a property named default, and can not make a
method in that sense. It makes my API inconsistent as I have to use a
getDefault, setDefault, when every other method is a single word.
Such as:
class Foo {
public $default;
public function default($default = null) {
if ($default === null) {
return $this-default;
}
$this-default = $default;
return $this;
}
}
This might not be the prefered way to write methods, but I don't see why
the language should restrict me from doing so because the word default is
used in a different context.
On Wed, Sep 18, 2013 at 5:19 PM, Matthew Leverton lever...@gmail.comwrote:
On Tue, Sep 17, 2013 at 7:50 PM, Stuart Langley slang...@google.com
wrote:
To be honest, looking at the example in the RFC, being able to define a
member function 'new' on a class that completely changes the semantics
of
the new operator is a great example of why you would not want this
feature.
It doesn't change anything because $foo-new() has no intrinsic
meaning in PHP. And I don't think the argument the programmer might
do something stupid ever holds much weight as a no vote against
anything. If somebody wants to create a confusing misnomer, he doesn't
need this proposed feature to do so.
But I agree that the RFC is missing any real-world examples of why it
might be useful, and that any new language feature should have
real-world benefits. Hopefully some more compelling reasons will be
added to the RFC.
Here's something that I've personally done with much shame:
class Where
{
private function _or($lhs, $op = null, $rhs = null)
{
}
public function __call($func_name, $args)
{
if ($func_name == 'or')
return call_user_func_array([$this, '_or'], $args);
}
}
$query-where('foo', '=', 1)-or('bar', '=', 2);
Imagine that $query-where() returns a Where object. I really want an
or method because it make things concise readable, but this is not
allowed. So I override the __call method to add such functionality,
which adds useless overhead.
There are a few keywords, such as list and unset, that I often wish I
could use in PHP. So in terms of readability, I think any sane
programmer would use this proposed functionality for good...
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Allowing is_* functions to accept multiple parameters
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
From the manual: If multiple parameters are supplied then isset() will
return TRUE only if all of the parameters are set. Evaluation goes from
left to right and stops as soon as an unset variable is encountered.
I am proposing that all of the is_* functions are allowed to take a
variable number of parameters and will return true if all of the arguments
satisfy what is being checked.
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
As well as producing much more succinct code and less function call
overhead, I think this ties in nicely with the variadic and unpacking RFCs
and is especially useful for parameters that cannot be typehinted; for
example you would be able to something like:
function doStuffWithNumbers(...$numbers) {
if (!is_int(...$numbers)) {
throw new InvalidArgumentException('blah');
...
Thoughts?
[PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
On Wednesday, September 18, 2013 at 12:53 PM, Leigh wrote:
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
From the manual: If multiple parameters are supplied then isset() will
return TRUE only if all of the parameters are set. Evaluation goes from
left to right and stops as soon as an unset variable is encountered.
I am proposing that all of the is_* functions are allowed to take a
variable number of parameters and will return true if all of the arguments
satisfy what is being checked.
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
As well as producing much more succinct code and less function call
overhead, I think this ties in nicely with the variadic and unpacking RFCs
and is especially useful for parameters that cannot be typehinted; for
example you would be able to something like:
function doStuffWithNumbers(...$numbers) {
if (!is_int(...$numbers)) {
throw new InvalidArgumentException('blah');
...
Thoughts?
are_int()
kindly,
nvartolomei
=)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Signature compatibility: Number of arguments
On Thu, Aug 29, 2013 at 11:33 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! This is a spinoff from the variadics thread. Quoting Stas: I also think this: public function query($query, ...$params) public function query(...$params) should be legal too. This is a general issue in PHP that we might want to fix: Currently a method A is not compatible with a method B if A has less arguments than B. E.g. both of the following are incompatible signatures: public function foo($bar) public function foo() public function foo($bar = NULL) public function foo() This doesn't really make sense. Removing parameters doesn't violate LSP, because in PHP it is legal to pass more arguments than declared. (Only adding additional required parameters would violate LSP.) Is it okay to change this? Thanks, Nikita Considering that we might support named parameters in the future I'm withdrawing this suggestion. This allows removing a parameter name, which would cause problems in that context. Nikita
Re: [PHP-DEV] Allowing is_* functions to accept multiple parameters
On Sep 18, 2013, at 11:53 AM, Leigh lei...@gmail.com wrote:
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
...
Thoughts?
For isset() there is a good reason to do this, because the var might not exist
at all, and as such you cannot use a function, as it would produce warnings.
However, for is_* functions, this could easily be done with a higher-order
every function. You pass a predicate and an array of values. It returns a
boolean.
Example:
if (!every('is_int', $numbers)) {
throw new \InvalidArgumentException(...);
}
Not only is that much cleaner in my opinion, it also is composable without
having to change *all* of the is_* predicates.
As such, I don't see much value in changing this.
Igor
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keywords as identifiers
Am 18.09.2013 um 09:28 schrieb David Neilsen da...@pan.co.nz:
missing any real-world examples of why it might be useful
One thing the I have run across in making my libraries, is the not being
able to call a function `default`.
I use the chainable getter/setter in one syntax a lot (a la jQuery). Hence
when I have a class with a property named default, and can not make a
method in that sense. It makes my API inconsistent as I have to use a
getDefault, setDefault, when every other method is a single word.
Such as:
class Foo {
public $default;
public function default($default = null) {
if ($default === null) {
return $this-default;
}
$this-default = $default;
return $this;
}
}
This might not be the prefered way to write methods, but I don't see why
the language should restrict me from doing so because the word default is
used in a different context.
On Wed, Sep 18, 2013 at 5:19 PM, Matthew Leverton lever...@gmail.comwrote:
On Tue, Sep 17, 2013 at 7:50 PM, Stuart Langley slang...@google.com
wrote:
To be honest, looking at the example in the RFC, being able to define a
member function 'new' on a class that completely changes the semantics of
the new operator is a great example of why you would not want this
feature.
It doesn't change anything because $foo-new() has no intrinsic
meaning in PHP. And I don't think the argument the programmer might
do something stupid ever holds much weight as a no vote against
anything. If somebody wants to create a confusing misnomer, he doesn't
need this proposed feature to do so.
But I agree that the RFC is missing any real-world examples of why it
might be useful, and that any new language feature should have
real-world benefits. Hopefully some more compelling reasons will be
added to the RFC.
Here's something that I've personally done with much shame:
class Where
{
private function _or($lhs, $op = null, $rhs = null)
{
}
public function __call($func_name, $args)
{
if ($func_name == 'or')
return call_user_func_array([$this, '_or'], $args);
}
}
$query-where('foo', '=', 1)-or('bar', '=', 2);
Imagine that $query-where() returns a Where object. I really want an
or method because it make things concise readable, but this is not
allowed. So I override the __call method to add such functionality,
which adds useless overhead.
There are a few keywords, such as list and unset, that I often wish I
could use in PHP. So in terms of readability, I think any sane
programmer would use this proposed functionality for good...
--
Matthew Leverton
Thank you all for your feedback; I was effectively missing a few concrete
examples.
I now added some examples.
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allowing is_* functions to accept multiple parameters
2013/9/18 Igor Wiedler i...@wiedler.ch
On Sep 18, 2013, at 11:53 AM, Leigh lei...@gmail.com wrote:
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
...
Thoughts?
For isset() there is a good reason to do this, because the var might not
exist at all, and as such you cannot use a function, as it would produce
warnings.
However, for is_* functions, this could easily be done with a higher-order
every function. You pass a predicate and an array of values. It returns a
boolean.
Example:
if (!every('is_int', $numbers)) {
throw new \InvalidArgumentException(...);
}
Actually it was about multiple parameters
if (!every('is_int', $a, $b, $c)) { /* .. */ }
To me using `is_int()` directly feels more intuitive too.
if (!is_int($a, $b, $c)) { /* .. */ }
Not only is that much cleaner in my opinion, it also is composable without
having to change *all* of the is_* predicates.
As such, I don't see much value in changing this.
Well, asking me that sounds like the same value like it is for
array_column(). It is a minor improvement, but it is an useful one (imo).
Just my 2 cent
Regards,
Sebastian
Igor
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
AW: [PHP-DEV] Allowing is_* functions to accept multiple parameters
function doStuffWithNumbers(...$numbers) {
if (!is_int(...$numbers)) {
throw new InvalidArgumentException('blah');
...
Thoughts?
Returning bool in this case will make it impossible to respond with a
meaningful error message. Which of the provided arguments !is_int()?
Instead, I would go with f.Ex.:
$numbers = array(...$numbers);
$result = array_filter($numbers, is_int)
and compare the arrays. Since the array keys are preserved, it's easy to
find out, which argument !is_int().
Finally, the imho best solution would still be introducing optional scalar
type hinting. But that is another topic and shouldn't be discussed here.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keywords as identifiers
Hi Bob, thanks for the RFC! For those of us that use token_get_all(), will the newly allowed token appear as T_STRING or as T_%KEYWORD%? May I suggest you add a word about it in the RFC? As Ryan pointed out in the other thread, a T_%KEYWORD% has a high chance to break existing documentation generators or code parsers. As Nikita remembered us, default in $a-default is emitted as a T_STRING. It might be consistent to also emit a T_STRING on the new cases that you plan to allow? Regards, Nicolas
Re: [PHP-DEV] Signature compatibility: Number of arguments
On Thu, Aug 29, 2013 at 11:33 AM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
This is a spinoff from the variadics thread. Quoting Stas:
I also think this:
public function query($query, ...$params)
public function query(...$params)
should be legal too.
This is a general issue in PHP that we might want to fix: Currently a
method A is not compatible with a method B if A has less arguments than B.
E.g. both of the following are incompatible signatures:
public function foo($bar)
public function foo()
public function foo($bar = NULL)
public function foo()
I dont really agree.
One could use reflection on the parameter, thus expecting it to be here on
a child instance :
class Foo
{
public function bar($arg = null) { }
}
class Foo2 extends Foo
{
public function bar() { }
}
$o = new Foo; /* Switching to Foo2 will lead to an Exception */
$r = new ReflectionParameter(array($o, 'bar'), 'arg');
echo $r-getName();
PS : I remember having a long discussion with Gustavo, some time ago, about
LSP in PHP ; and we could not agree on some points, particularly concerning
optional parameters.
Julien.Pauli
Re: [PHP-DEV] Allowing is_* functions to accept multiple parameters
On 18 September 2013 12:15, Igor Wiedler i...@wiedler.ch wrote:
for is_* functions, this could easily be done with a higher-order every
function. You pass a predicate and an array of values. It returns a boolean.
Example:
if (!every('is_int', $numbers)) {
throw new \InvalidArgumentException(...);
}
Not only is that much cleaner in my opinion, it also is composable without
having to change *all* of the is_* predicates.
Might just be me, but I don't really like having function names as
strings (obviously I use it when I _have_ to, but I try and stay away
from it otherwise).
Feedback I'm really interested in is what issues could arise from
changing those predicates. I'm pretty short sighted in this regard,
and mainly see the benefits I would gain from this change, so looking
for more This is a terrible idea because... kind of stuff.
On 18 September 2013 13:21, Frank Liepert frank.liep...@gmx.de wrote:
Returning bool in this case will make it impossible to respond with a
meaningful error message. Which of the provided arguments !is_int()?
I agree that it doesn't fit every case, and it's not supposed to. The
same can be said of isset(), if it is important to know which argument
was not set, then you have to use multiple calls.
On 18 September 2013 13:21, Frank Liepert frank.liep...@gmx.de wrote:
Finally, the imho best solution would still be introducing optional scalar
type hinting. But that is another topic and shouldn't be discussed here.
I agree, (both that it would be better, and that it is another topic
entirely - one which usually goes in circles, so lets stay away from
it here :))
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keywords as identifiers
Am 18.09.2013 um 14:30 schrieb Nicolas Grekas nicolas.grekas+...@gmail.com: Hi Bob, thanks for the RFC! For those of us that use token_get_all(), will the newly allowed token appear as T_STRING or as T_%KEYWORD%? May I suggest you add a word about it in the RFC? As Ryan pointed out in the other thread, a T_%KEYWORD% has a high chance to break existing documentation generators or code parsers. As Nikita remembered us, default in $a-default is emitted as a T_STRING. It might be consistent to also emit a T_STRING on the new cases that you plan to allow? Regards, Nicolas Absolutely true; this will still emit a keyword token. The reason is some limitation of the lexer which allows me to switch to a mode after I have encountered for example a :: (e.g. lookbehind), but it doesn't allow me lookaheads. If you have an idea how to circumwent that; I'm open to any suggestions. Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the short-circuiting
with ``:
?php
function are_null() {
foreach (func_get_args() as $a) {
if ($a !== null) {
return false;
}
}
return true;
}
function destroy_data() { echo DESTROYING DATA\n; }
// old form: short-circuited; data is not destroyed
if (is_null(null) is_null(false) is_null(destroy_data())) {
echo All null.\n;
} else {
echo Not null.\n;
}
echo \n;
// proposed form: no short-circuit; parameters are evaluated at call time and
data is destroyed
if (are_null(null, false, destroy_data())) {
echo Still null.\n;
} else {
echo Still not null.\n;
}
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
I like the naming convention of are_*. For me personally it isn't directly
intuitive that the multiple parameters of is_* would be compared with an
and not an ||.
On Wed, Sep 18, 2013 at 7:50 AM, Sean Coates s...@seancoates.com wrote:
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the short-circuiting
with ``:
?php
function are_null() {
foreach (func_get_args() as $a) {
if ($a !== null) {
return false;
}
}
return true;
}
function destroy_data() { echo DESTROYING DATA\n; }
// old form: short-circuited; data is not destroyed
if (is_null(null) is_null(false) is_null(destroy_data())) {
echo All null.\n;
} else {
echo Not null.\n;
}
echo \n;
// proposed form: no short-circuit; parameters are evaluated at call time
and data is destroyed
if (are_null(null, false, destroy_data())) {
echo Still null.\n;
} else {
echo Still not null.\n;
}
Re: [PHP-DEV] PHP CLI setting cooked terminal mode
On Tue, Sep 17, 2013 at 08:28:58AM +0200, Remi Collet wrote: Please... don't rely, for distro packaged PHP on configure option listed in phpinfo report [1]. Additional Modules Module Name readline readline extension doesn't use readline library (under incompatible license: GPLv3) but libedit (License: BSD). Running php and looking at the /proc/../maps file I see that it has mapped /usr/lib64/libedit.so.0.0.27 Looking at the symbol table I see the symbol tcsetattr -- this sets terminal modes in the way that I was seeing from the system call trace. What is needed is for this to NOT be called if the standard output is not connected to a tty. Should I raise this as a bug ? Remi. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI setting cooked terminal mode
Le 18/09/2013 16:04, Alain Williams a écrit :
What is needed is for this to NOT be called if the standard output is not
connected to a tty.
From your previous message:
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...})
= 0
Which is standard input, not standard output
I can get it to not do this by connecting stdin to /dev/null:
./myScript /dev/null | less
qed
Should I raise this as a bug ?
So, I don't think there is any bug there.
Remi.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI setting cooked terminal mode
On Wed, Sep 18, 2013 at 04:13:39PM +0200, Remi Collet wrote:
Le 18/09/2013 16:04, Alain Williams a écrit :
What is needed is for this to NOT be called if the standard output is not
connected to a tty.
From your previous message:
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo
...}) = 0
Which is standard input, not standard output
Yes - a typeo, sorry.
I can get it to not do this by connecting stdin to /dev/null:
./myScript /dev/null | less
qed
Should I raise this as a bug ?
So, I don't think there is any bug there.
The redirection of stdin to /dev/null is NOT a solution. You don't need to do
this with scripts written in other languages (eg shell, perl). It makes using
the script for the end user more difficult and strangely different from scripts
written in other languages.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keywords as identifiers
http://news.php.net/php.internals/23254 -ralph On 9/16/13 7:53 AM, Bob Weinand wrote: Hi! This is the (official) RFC thread for the patch proposed in http://php.markmail.org/message/7rn4mbwkbytqa3ig https://wiki.php.net/rfc/keywords_as_identifiers Any feedback about the RFC or the implementation? Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI setting cooked terminal mode
On Wed, Sep 18, 2013 at 4:20 PM, Alain Williams a...@phcomp.co.uk wrote:
On Wed, Sep 18, 2013 at 04:13:39PM +0200, Remi Collet wrote:
Le 18/09/2013 16:04, Alain Williams a écrit :
What is needed is for this to NOT be called if the standard output is
not
connected to a tty.
From your previous message:
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon
echo ...}) = 0
Which is standard input, not standard output
Yes - a typeo, sorry.
I can get it to not do this by connecting stdin to /dev/null:
./myScript /dev/null | less
qed
Should I raise this as a bug ?
So, I don't think there is any bug there.
The redirection of stdin to /dev/null is NOT a solution. You don't need to
do
this with scripts written in other languages (eg shell, perl). It makes
using
the script for the end user more difficult and strangely different from
scripts
written in other languages.
One could use ltrace -l to trace library calls.
On my laptop (Debian) :
ltrace -l /usr/lib/x86_64-linux-gnu/libedit.so.2 php -a
using_history(1, 38, 0x25000f, 712, 0x1087900) = 0
Interactive shell
tilde_expand(0xd48ef1, 0x24a0ae8, 0, 17, 149464)=
0x24c61c0
read_history(0x24c61c0, 0x7f0a6eb9f986, 0x8e0f5f, 0x7f0a6eb9f986, 0)= 0
readline(php php
Julien.Pauli
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
2013/9/18 Sean Coates s...@seancoates.com:
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the short-circuiting
with ``:
?php
function are_null() {
foreach (func_get_args() as $a) {
if ($a !== null) {
return false;
}
}
return true;
}
function destroy_data() { echo DESTROYING DATA\n; }
// old form: short-circuited; data is not destroyed
if (is_null(null) is_null(false) is_null(destroy_data())) {
echo All null.\n;
} else {
echo Not null.\n;
}
echo \n;
// proposed form: no short-circuit; parameters are evaluated at call time and
data is destroyed
if (are_null(null, false, destroy_data())) {
echo Still null.\n;
} else {
echo Still not null.\n;
}
Not a good idea IMHO: it would complexify the execution a lot, think about:
$test = are_null;
if ($test(null, false, destroy_data())) {
echo Still null.\n;
} else {
echo Still not null.\n;
}
Looking at the AST wouldn't be enough to tell what would or wouldn't
be short-circuited.
It looks fine to have is_* functions working on multiple values as
Leigh originally proposed. I also feel that it would mostly be
used/useful on variables.
People worrying about performance and/or execution of code with
short-circuiting can (and should) still rely on .
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
Not a good idea IMHO: it would complexify the execution a lot, think about: To be clear, I wasn't proposing an alternative. I was just pointing out that function call semantics are not the same as conditional (short-circuit) semantics, as they appeared in the OP. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
2013/9/18 Chris London m...@chrislondon.co: I like the naming convention of are_*. For me personally it isn't directly intuitive that the multiple parameters of is_* would be compared with an and not an ||. isset() already operates that way, keeping is_ and implementing it as originally proposed by Leigh would, at least, be consistent. [Derick mode: on] PS: top posting is not #cool. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
2013/9/18 Sean Coates s...@seancoates.com: Not a good idea IMHO: it would complexify the execution a lot, think about: To be clear, I wasn't proposing an alternative. I was just pointing out that function call semantics are not the same as conditional (short-circuit) semantics, as they appeared in the OP. That is true! Something to take in mind for the documentation if this is going to be implemented! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keywords as identifiers
Am Mittwoch, 18. September 2013 um 16:29 schrieb Ralph Schindler: http://news.php.net/php.internals/23254 -ralph On 9/16/13 7:53 AM, Bob Weinand wrote: Hi! This is the (official) RFC thread for the patch proposed in http://php.markmail.org/message/7rn4mbwkbytqa3ig https://wiki.php.net/rfc/keywords_as_identifiers Any feedback about the RFC or the implementation? I really like the proposal. I cannot count how often I tried to create a class called „List“ and failed miserably. Cheers Jannik
Re: [PHP-DEV] PHP CLI setting cooked terminal mode
On Wed, Sep 18, 2013 at 04:33:50PM +0200, Julien Pauli wrote:
One could use ltrace -l to trace library calls.
On my laptop (Debian) :
ltrace -l /usr/lib/x86_64-linux-gnu/libedit.so.2 php -a
using_history(1, 38, 0x25000f, 712, 0x1087900) = 0
Interactive shell
Thanks - that helps. That is called in PHP_MINIT_FUNCTION(readline)
in ./ext/readline/readline.c
I have modified the initialisation function as below, using isatty() on STDIN
STDOUT. This will stop readline being initialised if it is not being used
interactively.
I have not even tried to compile this, I don't understand enough about how it
all hangs together to know if it will work - one concern is that if the PHP
script tries to read from STDIN it might all fail, all of the readline stuff
should probably return FALSE if it has not initialised.
PHP_MINIT_FUNCTION(readline)
{
/* Do not start readline if not connected to a terminal on both STDIN
STDOUT */
if( !isatty(0) || !isatty(1))
return SUCCESS;
using_history();
return PHP_MINIT(cli_readline)(INIT_FUNC_ARGS_PASSTHRU);
}
BTW: this code has changed between php-5.5.3 php-5.3.3. The version that I
have been using is PHP 5.3.3. The code above is from PHP 5.5.3.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
On 18 September 2013 14:50, Sean Coates s...@seancoates.com wrote: i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b) is_null($c) Note that this would not be semantically equivalent in this form, even if `is_null()` did accept multiple parameters, because of the short-circuiting with ``: See below. On 18 September 2013 15:53, Patrick ALLAERT patrickalla...@php.net wrote: 2013/9/18 Chris London m...@chrislondon.co: I like the naming convention of are_*. For me personally it isn't directly intuitive that the multiple parameters of is_* would be compared with an and not an ||. isset() already operates that way, keeping is_ and implementing it as originally proposed by Leigh would, at least, be consistent. Indeed, my proposal was to mimic short circuiting as isset() does it, evaluating LTR and returning false at the earliest opportunity. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
Am 18.9.2013 um 18:09 schrieb Leigh lei...@gmail.com:
On 18 September 2013 14:50, Sean Coates s...@seancoates.com wrote:
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the short-circuiting
with ``:
See below.
On 18 September 2013 15:53, Patrick ALLAERT patrickalla...@php.net wrote:
2013/9/18 Chris London m...@chrislondon.co:
I like the naming convention of are_*. For me personally it isn't directly
intuitive that the multiple parameters of is_* would be compared with an
and not an ||.
isset() already operates that way, keeping is_ and implementing it
as originally proposed by Leigh would, at least, be consistent.
Indeed, my proposal was to mimic short circuiting as isset() does it,
evaluating LTR and returning false at the earliest opportunity.
At least, from a technical point, evaluating LTR would require to change the
engine
(would be some more complex change as it would require to switch between
contexts
and being able to execute the ZEND_SEND_VAL opcodes one by one (evaluate
first argument and execute until next ZEND_SEND_VAL, and if one doesn't match
the
conditions, jump to the end of the sending args) etc.) Just have a look at the
complicated
opcodes, just for isset: http://3v4l.org/l3Z4l/vld And now do something like
this for real
functions (e.g. not a language construct) at run-time, because we'd have to do
the
function lookup at run-time (just because the name of the function might be
unknown at
compile time thanks to $var = func; $var();)
The other alternative here is (like isset), just changing it into a language
construct.
(which I consider also suboptimal, as it disallows still things like
$var = is_*; $var($arg1, $arg2, $arg3);).
So, I am basically -1 on this, as this a) requires some deep engine change in
the
opcodes' handling flow or needs a change of language parser (well, if someone
could
provide a nice patch which implements this in a nice way, I'm in favor of this)
and
b) without LTR it effectively needs to evaluate everything, what would be
a performance drop as opposed to the current (encouraged) method of just
and'ing all
the is_* calls. Then you also just could do in userspace code (with an
one-liner):
function are_int (...$args) {
return count($args) == count(array_filter(is_int, $args));
}
So: tl;dr: only in favour if technically not too complicated and doesn't have
the restrictions of
a typical language construct. Else: -1.
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support for keywords where possible
Hi Bob: It's now only for class/interface/trait, label and method names. Sure, that's not as bad. A bigger concern of mine is the added compatibility problem with new code possibly not being able to run on older PHP versions. That cost seems greater than the benefit of some developers being able to call $o-default() instead of $o-get_default(). Thanks for your consideration, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support for keywords where possible
Hi Bob: Well, that makes no sense. Then you just could say no to all new language changes. Because it cannot be run on older versions. Allow me one last post to clarify. What I said is the cost in _this_ case doesn't outweigh the advantages. As someone who writes a lot of open source (and proprietary) code that gets run on machines that I have no control over, implementing this proposal will complicate my life. Every time I make a function I'll have to ask myself is this a reserved word in older versions of PHP? I'll leave the discussion at that. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support for keywords where possible
On 18/09/2013 19:25, Daniel Convissor wrote: Allow me one last post to clarify. What I said is the cost in _this_ case doesn't outweigh the advantages. As someone who writes a lot of open source (and proprietary) code that gets run on machines that I have no control over, implementing this proposal will complicate my life. Every time I make a function I'll have to ask myself is this a reserved word in older versions of PHP? I'll leave the discussion at that. You're going to have to ask that question anyway. It's not a good reason to not do it. As some point you're not going to be wanting to support ancient PHP versions and you'll be able to do what you like. Continue as-is like there was no change and you'll never have an issue. There's no cost. Regards smime.p7s Description: S/MIME Cryptographic Signature
Re: [PHP-DEV] Support for keywords where possible
Am 18.9.2013 um 19:53 schrieb Daniel Convissor dani...@analysisandsolutions.com: Hi Bob: It's now only for class/interface/trait, label and method names. Sure, that's not as bad. A bigger concern of mine is the added compatibility problem with new code possibly not being able to run on older PHP versions. That cost seems greater than the benefit of some developers being able to call $o-default() instead of $o-get_default(). Thanks for your consideration, --Dan Well, that makes no sense. Then you just could say no to all new language changes. Because it cannot be run on older versions. (yes, you CAN change the hoster if he doesn't provide the newest PHP version, or (when you have the rights to) just upgrade it yourself.) This is really a non-argument. Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support for keywords where possible
Hi Bob: Well, that makes no sense. Then you just could say no to all new language changes. Because it cannot be run on older versions. Allow me one last post to clarify. What I said is the cost in _this_ case doesn't outweigh the advantages. As someone who writes a lot of open source (and proprietary) code that gets run on machines that I have no control over, implementing this proposal will complicate my life. Every time I make a function I'll have to ask myself is this a reserved word in older versions of PHP? I'll leave the discussion at that. Thanks, --Dan Really? Really?! If you don't want to use (un)reserved keywords, just don't, regardless of if it's allowed in PHPX and not in PHPY, why do you care if it's implemented for those who do want it available? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support for keywords where possible
On Wed, Sep 18, 2013 at 2:25 PM, Daniel Convissor dani...@analysisandsolutions.com wrote: As someone who writes a lot of open source (and proprietary) code that gets run on machines that I have no control over, implementing this proposal will complicate my life. Every time I make a function I'll have to ask myself is this a reserved word in older versions of PHP? You have to do this with _any_ relatively new PHP feature (namespaces, traits, generators, etc) that is implemented; how is this any different?
Re: [PHP-DEV] Support for keywords where possible
On Sep 18, 2013 10:53 AM, Daniel Convissor dani...@analysisandsolutions.com wrote: Hi Bob: It's now only for class/interface/trait, label and method names. Sure, that's not as bad. A bigger concern of mine is the added compatibility problem with new code possibly not being able to run on older PHP versions. That cost seems greater than the benefit of some developers being able to call $o-default() instead of $o-get_default(). Thanks for your consideration, Well, it is a good point but impossible to keep without killing any future language improvements. Think of generators f.e.
Re: [PHP-DEV] free deadlock in timeout signal handler
On 13/09/13 22:10, Lazy wrote:
Hello internals,
I'm trying to fix deadlock in an ancient php 5.2.17, php hangs on
internal libc lock.
From my understanding free is not safe to use in a signal handler, and
this seems to be the issue here.
No, it's not.
http://marc.info/?l=php-internalsm=121999390109071w=2 seems to
address this issue but it's not present in 5.3 or later releases.
Very similar deadlock but with time() instead of free(),
https://bugs.php.net/bug.php?id=31749
Are you sure it's with time() ? I do see a free() in that call stack
(and no time),
as I would expect, as time() is required by POSIX.1-2004 to be
Async-signal-safe.
Current php also uses free() in php_error_cb() and external
destructors in list_entry_destructor() aren't protected by
HANDLE_BLOCK_INTERRUPTIONS() (which seems to be a noop in fastcgi
mode), so I suspect 5.5 may also contain this deadlock.
main/main.c
php_error_cb()
835 if (display) {
836 if (PG(last_error_message)) {
837 free(PG(last_error_message));
...^^ deadlock if previous free was
interrupted by a timeout signal
845 PG(last_error_type) = type;
846 PG(last_error_message) = strdup(buffer);
I'm thinking about fixing this by leaking memory pointed by
PG(last_error_message) if php called when a timeout is pending
(timeouts are usually very rare, php processes will eventually be
restarted so this little memory waste won't have time to make any
impact.
Is this issue fixed in modern php ? If so I would be grateful for some
information about the way it was done. This would save me a lot of
time trying to trigger
a non existing confition.
I will try to reproduce this in a modern version of php.
It probably isn't. PG(last_error_message) is only modified in main.c, I
would try to use a separate arena for PG(last_error_message) and
PG(last_error_file). For instance it could be a static buffer reused
during the whole execution and extended with mmap(2) in the unlikely
case it turns out to be too small. I suspect it would also make the
error handler faster, as it would avoid the free() + malloc()
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
On 18 September 2013 18:50, Bob Weinand bobw...@hotmail.com wrote: At least, from a technical point, evaluating LTR would require to change the engine (would be some more complex change as it would require to switch between contexts and being able to execute the ZEND_SEND_VAL opcodes one by one Feels like you're overthinking it? Plan was to allow any is_* function to be called as normal (SEND_VAR, SEND_VAR ... FCALL), then iterate over the supplied arguments inside the function and return false at the first failure, emulating the boolean short circuit. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
Am 18.09.2013 um 21:57 schrieb Leigh lei...@gmail.com: On 18 September 2013 18:50, Bob Weinand bobw...@hotmail.com wrote: At least, from a technical point, evaluating LTR would require to change the engine (would be some more complex change as it would require to switch between contexts and being able to execute the ZEND_SEND_VAL opcodes one by one Feels like you're overthinking it? Plan was to allow any is_* function to be called as normal (SEND_VAR, SEND_VAR ... FCALL), then iterate over the supplied arguments inside the function and return false at the first failure, emulating the boolean short circuit. Well, the arguments are executed at the moment where the ZEND_SEND_VAR op is encountered. But this you already can do with the one liner in my last mail. So LTR support is basically not worth it here (too many change/too much cost for this). Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting SG(request_info).post_data/raw_post_data on master branch?
On Wed, Sep 18, 2013 at 4:19 PM, Michael Wallner m...@php.net wrote: Did the suggestion from UPGRADING.INTERNALS to use the php://input wrapper work out for you? Maybe I should add a comment inline... Thank you for the tip. It worked very well. I read your patch didn't read UPGRADING.INTERNALS carefully. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On 16/09/13 15:58, Daniel Lowrey wrote: More generally, PHP's stream encryption aspects are quite poorly documented. For example, https:// streams disable peer verification by default. While I understand that this is necessary to provide the easiest possible user experience for things like `file_get_contents( https://somesite.com;)`, it's also horribly insecure. 99% of people using tools like this won't know anything about this feature and won't realize that their stream transfers are totally vulnerable to Man-in-the-Middle attacks by default. Count me as one of those that didn't know https:// streams didn't verify certificates. :) *I consider this a bug* I understand that it's easier to code not verifying the peer, and the hostname may not be available when you are stacking ssl over a stream. But file_get_contents(https://...;) is *precisely* the case that should work right out of the box. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
Ángel González wrote: On 16/09/13 15:58, Daniel Lowrey wrote: More generally, PHP's stream encryption aspects are quite poorly documented. For example, https:// streams disable peer verification by default. While I understand that this is necessary to provide the easiest possible user experience for things like `file_get_contents( https://somesite.com;)`, it's also horribly insecure. 99% of people using tools like this won't know anything about this feature and won't realize that their stream transfers are totally vulnerable to Man-in-the-Middle attacks by default. Count me as one of those that didn't know https:// streams didn't verify certificates. :) While we're on the topic, it's actually worse than that. Even if you turn peer validation and name checking on, PHP can't handle subjectAltNames in certificates, which causes quite a few failures. (For example: GitHub's certificate is for *.github.com, but the subjectAltName contains *.github.com and github.com so they can use a single certificate. PHP will hence believe that github.com does not have a valid certificate.) I recently had to work around this in userland: https://github.com/rmccue/Requests/pull/63 and http://core.trac.wordpress.org/ticket/25007 - which to my knowledge, are the only HTTP clients in userland that go this far for validation. -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On Thu, Sep 19, 2013 at 8:33 AM, Ángel González keis...@gmail.com wrote: On 16/09/13 15:58, Daniel Lowrey wrote: More generally, PHP's stream encryption aspects are quite poorly documented. For example, https:// streams disable peer verification by default. While I understand that this is necessary to provide the easiest possible user experience for things like `file_get_contents( https://somesite.com;)`, it's also horribly insecure. 99% of people using tools like this won't know anything about this feature and won't realize that their stream transfers are totally vulnerable to Man-in-the-Middle attacks by default. Count me as one of those that didn't know https:// streams didn't verify certificates. :) *I consider this a bug* I understand that it's easier to code not verifying the peer, and the hostname may not be available when you are stacking ssl over a stream. But file_get_contents(https://...**;) is *precisely* the case that should work right out of the box. To be practical, verifying certificates requires an up-to-date CA bundle to be shipped with PHP; perhaps this is a simple thing to do, I'm not sure. This is an oft seen scenario for cURL; the developer would see the certificate issue, search online and continue with `CURLOPT_VERIFY_PEER = 0`. That said, at least cURL is configured to check the certificate by default. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Tjerk
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
I would argue that LTR support is also inconsistent / not desired. If I wrote: $i = 0; is_three($i = $i + 1, $i = $i + 1, $i = $i + 1); I would certainly expect is_three to return false, but I would also expect $i to contain three. php doesn't normally evaluate arguments lazily, it would be weird for that behavior to suddenly crop up. users who want lazy evaluation can write it the traditional way (with ). PS - hi, this is my first post on php-internals though i've been reading for like a month. -Will Bartett -- William Bartlett College of Engineering | Cornell University '14 240-432-5189 On Wed, Sep 18, 2013 at 4:05 PM, Bob Weinand bobw...@hotmail.com wrote: Am 18.09.2013 um 21:57 schrieb Leigh lei...@gmail.com: On 18 September 2013 18:50, Bob Weinand bobw...@hotmail.com wrote: At least, from a technical point, evaluating LTR would require to change the engine (would be some more complex change as it would require to switch between contexts and being able to execute the ZEND_SEND_VAL opcodes one by one Feels like you're overthinking it? Plan was to allow any is_* function to be called as normal (SEND_VAR, SEND_VAR ... FCALL), then iterate over the supplied arguments inside the function and return false at the first failure, emulating the boolean short circuit. Well, the arguments are executed at the moment where the ZEND_SEND_VAR op is encountered. But this you already can do with the one liner in my last mail. So LTR support is basically not worth it here (too many change/too much cost for this). Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Keywords as identifiers
I have run all the PHPT tests from the latest master test-pack against builds with this patch on Windows (all versions 2008+): I get the same failures I get from recent master builds. The patch doesn't break anything on Windows. You can get the PHP builds for Windows with this patch that I used here: http://windows.php.net/downloads/snaps/ostc/build/keywords/ When I first heard the title of the patch, it sounded like it was frivolous, but the examples of how it would be useful really show that it would be useful (fe List, doc generators, DSLs). I think this is a great change to the language. Date: Wed, 18 Sep 2013 17:14:54 +0200 From: he...@apfelbox.net To: ra...@ralphschindler.com CC: internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Keywords as identifiers Am Mittwoch, 18. September 2013 um 16:29 schrieb Ralph Schindler: http://news.php.net/php.internals/23254 -ralph On 9/16/13 7:53 AM, Bob Weinand wrote: Hi! This is the (official) RFC thread for the patch proposed in http://php.markmail.org/message/7rn4mbwkbytqa3ig https://wiki.php.net/rfc/keywords_as_identifiers Any feedback about the RFC or the implementation? I really like the proposal. I cannot count how often I tried to create a class called „List“ and failed miserably. Cheers Jannik
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
While we're on the topic, it's actually worse than that. Even if you turn peer validation and name checking on, PHP can't handle subjectAltNames in certificates, which causes quite a few failures. This is incorrect. PHP has supported both the SNI_enabled and SNI_server_name SSL context options since 5.3. Anything older than 5.3 is not remotely worth worrying over. You can verify this for yourself using the following code: ?php // reference: http://php.net/manual/en/context.ssl.php $ctx = stream_context_create(['ssl' = [ 'verify_peer' = TRUE, 'cafile' = '/path/to/cacert.pem', // -- change to point to an actual CA file 'SNI_enabled' = TRUE ]]); $uri = https://sni.velox.ch/ // --- A test site using SNI certs $result = file_get_contents($uri, FALSE, $ctx); P.S. Thank you to whomever updated http://php.net/manual/en/context.ssl.phpto reflect the disable_compression SSL stream context option (and subsidized my laziness) :) On Wed, Sep 18, 2013 at 9:06 PM, Tjerk Anne Meesters datib...@php.netwrote: On Thu, Sep 19, 2013 at 8:33 AM, Ángel González keis...@gmail.com wrote: On 16/09/13 15:58, Daniel Lowrey wrote: More generally, PHP's stream encryption aspects are quite poorly documented. For example, https:// streams disable peer verification by default. While I understand that this is necessary to provide the easiest possible user experience for things like `file_get_contents( https://somesite.com;)`, it's also horribly insecure. 99% of people using tools like this won't know anything about this feature and won't realize that their stream transfers are totally vulnerable to Man-in-the-Middle attacks by default. Count me as one of those that didn't know https:// streams didn't verify certificates. :) *I consider this a bug* I understand that it's easier to code not verifying the peer, and the hostname may not be available when you are stacking ssl over a stream. But file_get_contents(https://...**;) is *precisely* the case that should work right out of the box. To be practical, verifying certificates requires an up-to-date CA bundle to be shipped with PHP; perhaps this is a simple thing to do, I'm not sure. This is an oft seen scenario for cURL; the developer would see the certificate issue, search online and continue with `CURLOPT_VERIFY_PEER = 0`. That said, at least cURL is configured to check the certificate by default. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Tjerk
