[PHP-DEV] Annotated PHP 5->7 extension diff

[Rasmus Lerdorf]

We have had quite a number of changes to the extension API and it
worries me a little bit how long it will take everyone to get their
extensions ported. We have UPGRADING.INTERNALS which still needs some
love, but even if that covered everything it is sometimes hard to match
a bullet point in a long list of changes to actual code.

Having just finished porting php-memcached (with help from Xinchen) to
PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
and explain why each change was made. The extension is complicated
enough to cover most of the changes the bulk of extension authors need
to worry about.

The diff is easy enough to grab:

  git clone https://github.com/php-memcached-dev/php-memcached.git
  cd php-memcached
  git checkout php7
  git diff master php7

It looks like this:

  https://gist.github.com/anonymous/15cbc9947edb4f0a71fd

Any suggestions for how to handle annotating it? We could turn it into a
fake PR and mark it up using github's PR comments. But is there
something more suited for this out there?

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Annotated PHP 5->7 extension diff

[Rasmus Lerdorf]

On Feb 5, 2015, at 17:41, "guilhermebla...@gmail.com" 
 wrote:
> 
> Hi Rasmus,
> 
> Thanks for the highlight.
> My biggest concern about all this breakage done for NG could somehow be 
> minimized by providing possible alternate implementations that could work 
> both backwards compatible and forwards compatible?
> I just don't want to work on extensions I support that would never be usable 
> in earlier versions once finished the update.
> 
> Maybe it would be interesting to have samples of before/after (like you did) 
> and also samples of of compatibility pieces for PHP 7- and PHP 7+.

That is one of the reasons an annotated diff would be good. All the changes in 
the diff aren't strictly needed. I didn't need to change from "s" to "S" in ZPP 
and the accompanying change to zend_string for example, but I find the new API 
cleaner and less error-prone. 

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Rasmus Lerdorf]

On 02/07/2015 05:03 PM, Pavel Kouřil wrote:
> I'm wishing more and more that the RFC doesn't pass (even though I'd
> LOVE to have typehints in PHP as a userland developer) and someone
> else will make a better version of typehints RFC for  PHP 7, because
> this one feels really like you took an ok-ish RFC (one that would be
> good for PHP) and slapped a strict typing on it without enough
> research about strong typing in other languages. And as I said myself
> multiple times in the past, the declare syntax IS just ugly (and
> changing how code works by writing one line is an ugly principle as
> well, IMHO). :(

I am not sure I would go that far. Andrea did plenty of research and has
tons of experience in other languages, I just think this approach is
misguided. I also wonder just how many people of those who voted even
bothered to download and try the patch. I tried it a while back on some
existing code and it was a nightmare. Does everyone realize that these
simple things break?

 tan(1);
 echo strstr("test", "est", 1);

Having absolutely no coercion for int to float and 0/1 to false/true,
especially for internal functions, is just too pedantic to me. I also
find this a bit hypocritical:

declare(strict_types=true);

outputs:

Fatal error: strict_types declaration must have 0 or 1 as its value

That is obviously nit-picking, but if we are going to get this pedantic...

And, you also have to realize that it isn't actually per file. For
example, this:



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Rasmus Lerdorf]

On 02/07/2015 09:51 PM, Andrea Faulds wrote:
>> tan(1);
>> echo strstr("test", "est", 1);
> 
> Banning int->float and float->int is both a pain point and sometimes a 
> life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you 
> discover if your ints floats would be silently truncated (as I did with 
> PictoSwap).
> 
> I wouldn’t say that int->string not working is a problem, though. Seeing 
> something like strstr(“test”, “est”, 1); is rather confusing. Looking at it, 
> I’d think the third parameter is some sort of number for you to want to pass 
> an integer to it. If I want a string, I’ll use one.

This isn't int->string. This is int->boolean. The 3rd arg to strstr() is
a boolean and passing 1 instead of true makes it blow up. It is very
very common for people to pass 0 or 1 in place of true/false to all
sorts of things in PHP.

> Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one 
> sense (like encoding, but unlike ticks, it has no effect on the including or 
> included files). However, it technically affects the remainder of the file, 
> not the whole file.

Well, no, not the remainder of the file either since it can be switched
again. It only affects the part of the file between declares if there is
a second one.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Rasmus Lerdorf]

On 02/10/2015 07:57 PM, Xinchen Hui wrote:
>> am I wrong?!
> seems I am wrong with this, it's a false alarm...  it can restore 
> automatically.

Yeah, declare() doesn't span files so that isn't a problem.

My worry is still the lack of type coercion for internal calls. I tested
it on some apps and it will take quite a bit of tedious and rather
useless effort to fix these to run in strict mode. Some examples of
common things that are fatal errors in strict mode:

  ini_set('precision', 14);

  ini_set('display_errors', 1);

  ini_set('display_errors', true);

  ok, not common, but tan(4/2) fatal, tan(5/2) no error

  Wordpress has this function, spot the error:

  function add_magic_quotes( $array ) {
foreach ( (array) $array as $k => $v ) {
if ( is_array( $v ) ) {
$array[$k] = add_magic_quotes( $v );
} else {
$array[$k] = addslashes( $v );
}
}
return $array;
  }

  $v may not always be a string (it died with a float for me), so the
  fix is to cast:

$array[$k] = addslashes( (string)$v );

  Also from Wordpress:

  $formatted = number_format( $number, absint( $decimals ),
$wp_locale->number_format['decimal_point'],
$wp_locale->number_format['thousands_sep'] );

  Here number_format() is expecting a float but $number is a string. So
  again, the only real fix is to cast.

  And in Drupal8 *without turning on strict*:

  use Drupal\Component\Utility\String;

  it dies with: "Fatal error: "string" cannot be used as a class name in
/var/www/drupal/core/includes/bootstrap.inc on line 11"

  That String class is everywhere in Drupal. They are going to have a
  fun time with that. See
https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1

  From Geeklog:

  if (strtolower($topic) != strtolower($archivetid)) {
$sql .= " AND ta.tid != '{$archivetid}' ";
  }

  $topic can be null there. Looking at the logic, not really a bug,
  just a natural reliance on null being coerced to ""

  Also from Geeklog:

if( empty( $date )) {
// Date is empty, get current date/time
$stamp = time();
} else if( is_numeric( $date )) {
// This is a timestamp
$stamp = $date;
} else {
// This is a string representation of a date/time
$stamp = strtotime( $date );
}
// Format the date
$date = strftime( $dateformat, $stamp );

strftime() expects an integer for the timestamp there, but as the
above logic shows, they are expecting a numeric string to be fine.
No bug, just another forced cast.

And another number_format() instance where arg1 is not necessarily
a float. Obviously not a bug, so we have to cast again:

return number_format( $number, $dc, $ds, $ts );

In Opencart:

$this->image = imagecreatetruecolor($width, $height);
imagecreatetruecolor() expects parameter 1 to be integer, string
given in /var/www/opencart/system/library/image.php on line 89

You could argue this is a bug, I guess, but the width and height are
coming from a database and are integers in the db, but since the db
returns strings. Another cast...

I was genuinely hoping to find some bugs with this exercise. I suppose
it is because I did it on mature projects and at this stage those sorts
of bugs have already been fixed. But I still fear that people are going
to want to be enable strictness everywhere and then they will quickly
learn that they better cast stuff to be safe which makes the whole thing
rather pointless. And I feel pretty sorry for the Drupal folks. That
list of 1000+ instances of their String class is going to suck to fix.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP 7 snapshots?

[Rasmus Lerdorf]

On 02/12/2015 01:39 PM, Jacob Bednarz wrote:
> Hi Internals,
> 
> Late in January Rasmus sent out an email to test the PHP 7 build.  I've
> recently completed this with a few of our applications locally however
> now I am looking to test these changes on one of our isolated
> development environments (yes, I'm aware of the risks and willing to
> take them in order to test the new release). The only problem is, I
> cannot find which tag/branch has these changes within it? Could someone
> please clarify this one for me?

PHP 7 is the master branch.




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [VOTE] Big Integer Support

[Rasmus Lerdorf]

On 02/15/2015 05:45 AM, Andrea Faulds wrote:
> Hi,
> 
>> On 15 Feb 2015, at 12:39, Xinchen Hui  wrote:
>>
>> On Sun, Feb 15, 2015 at 10:46 AM, Andrea Faulds  wrote:
>>> Hi everyone,
>>>
>>> I should’ve done this a long time ago, but I’m going to hold a vote on this 
>>> RFC. The implementation isn’t finished, but the remaining work isn’t 
>>> impossible to surmount (though help would certainly be appreciated). RFCs 
>>> can be put to vote without implementations (or so says 
>>> https://wiki.php.net/rfc/howto), so the fact the implementation is 
>>> unfinished isn’t necessarily a blocker.
>> for such a big change, the implementation self is also important,
>> there was some RFC accepted with "not good" implementation, which
>> cause lots of troubles for us to maintaining .
> 
> This vote isn’t to be thought of as accepting the implementation, merely the 
> feature. If the implementation isn’t good enough, the feature could actually 
> be dropped for PHP 7, as much as I hope that won’t happen.

At 4 weeks before the feature freeze, we pretty much have to vote for
the implementation as well. Every feature that requires significant work
puts more pressure on a small group of developers and takes their time
away from working on stabilizing the existing code base.

My no vote is based on looking at the implementation, the size of the
patch and the destabilizing changes to the extension API weighed against
its benefits.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Switch jumptable optimization

[Rasmus Lerdorf]

On 02/16/2015 03:04 PM, Bob Weinand wrote:
> I'd like to show you my recent work on a jumptable optimization for switches.
> 
> https://github.com/php/php-src/pull/1048 
> 
> 
> It is a fully transparent optimization of switches, by putting a new 
> ZEND_SWITCH opcode at the top of the switch in case we can build a jumptable, 
> which is the case if the cases are only scalars (no doubles) or evaluate to 
> them at compile-time.
> 
> Switches tend to be big sometimes with a lot of static (literals or constants 
> usually) cases, which was a comparison for each case, and now just a simple 
> hashtable lookup is needed, which greatly improves performance. In case where 
> the result of the switch can be determined at compile-time, it even replaces 
> the comparisons with a simple ZEND_JMP opcode.
> 
> In synthetic benchmarks the results are mind blowing, but in practice, 
> benefits mostly are stateful userland parsers (often called with sometimes 
> big switches), where it makes it a few percent faster. (For more concrete 
> numbers see https://github.com/php/php-src/pull/1048#issuecomment-73032647)
> 
> As the optimization is only done if there are 3 or more cases, the lookup is 
> always faster than the single comparisons. So there's no negative performance 
> impact.
> 
> It already works, except with opcache where the CFG optimization pass still 
> lacks support. Dmitry or Laruence volunteered to add support for opcache.
> 
> I'd like to know if there are any technical objections to the PR. If not, 
> they will add opcache support and merge it in.

It looks ok to me if Xinchen or Dmitry gets the opcache support working
for it and the feature is stabilized in time. I gave it a try and it is
segfaulting for me (no opcache):

==5612== Command: sapi/cli/php -n jump.php
==5612==
==5612== Invalid read of size 4
==5612==at 0xA64637: _zend_is_inconsistent (zend_hash.c:44)
==5612==by 0xA65749: _zend_hash_add_or_update_i (zend_hash.c:427)
==5612==by 0xA65AF9: _zend_hash_add (zend_hash.c:489)
==5612==by 0xA37E28: zend_hash_add_ptr (zend_hash.h:458)
==5612==by 0xA39B0A: zend_hash_add_constant (zend_constants.c:486)
==5612==by 0xA39D01: zend_register_constant (zend_constants.c:523)
==5612==by 0xA389E9: zend_register_long_constant (zend_constants.c:194)
==5612==by 0xA3855C: zend_register_standard_constants
(zend_constants.c:116)
==5612==by 0xA52D6E: zend_startup (zend.c:671)
==5612==by 0x9C7FAA: php_module_startup (main.c:2099)
==5612==by 0xAFA460: php_cli_startup (php_cli.c:421)
==5612==by 0xAFC4D6: main (php_cli.c:1335)
==5612==  Address 0x8 is not stack'd, malloc'd or (recently) free'd

And jump.php is:



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Switch jumptable optimization

[Rasmus Lerdorf]

On 02/16/2015 03:47 PM, Bob Weinand wrote:
>> Am 17.02.2015 um 00:30 schrieb Rasmus Lerdorf > <mailto:ras...@lerdorf.com>>:
>>
>> On 02/16/2015 03:04 PM, Bob Weinand wrote:
>>> I'd like to show you my recent work on a jumptable optimization for
>>> switches.
>>>
>>> https://github.com/php/php-src/pull/1048
>>> <https://github.com/php/php-src/pull/1048>
>>>
>>> It is a fully transparent optimization of switches, by putting a new
>>> ZEND_SWITCH opcode at the top of the switch in case we can build a
>>> jumptable, which is the case if the cases are only scalars (no
>>> doubles) or evaluate to them at compile-time.
>>>
>>> Switches tend to be big sometimes with a lot of static (literals or
>>> constants usually) cases, which was a comparison for each case, and
>>> now just a simple hashtable lookup is needed, which greatly improves
>>> performance. In case where the result of the switch can be determined
>>> at compile-time, it even replaces the comparisons with a simple
>>> ZEND_JMP opcode.
>>>
>>> In synthetic benchmarks the results are mind blowing, but in
>>> practice, benefits mostly are stateful userland parsers (often called
>>> with sometimes big switches), where it makes it a few percent faster.
>>> (For more concrete numbers see
>>> https://github.com/php/php-src/pull/1048#issuecomment-73032647)
>>>
>>> As the optimization is only done if there are 3 or more cases, the
>>> lookup is always faster than the single comparisons. So there's no
>>> negative performance impact.
>>>
>>> It already works, except with opcache where the CFG optimization pass
>>> still lacks support. Dmitry or Laruence volunteered to add support
>>> for opcache.
>>>
>>> I'd like to know if there are any technical objections to the PR. If
>>> not, they will add opcache support and merge it in.
>>
>> It looks ok to me if Xinchen or Dmitry gets the opcache support working
>> for it and the feature is stabilized in time. I gave it a try and it is
>> segfaulting for me (no opcache):
>>
>> ==5612== Command: sapi/cli/php -n jump.php
>> ==5612==
>> ==5612== Invalid read of size 4
>> ==5612==at 0xA64637: _zend_is_inconsistent (zend_hash.c:44)
>> ==5612==by 0xA65749: _zend_hash_add_or_update_i (zend_hash.c:427)
>> ==5612==by 0xA65AF9: _zend_hash_add (zend_hash.c:489)
>> ==5612==by 0xA37E28: zend_hash_add_ptr (zend_hash.h:458)
>> ==5612==by 0xA39B0A: zend_hash_add_constant (zend_constants.c:486)
>> ==5612==by 0xA39D01: zend_register_constant (zend_constants.c:523)
>> ==5612==by 0xA389E9: zend_register_long_constant
>> (zend_constants.c:194)
>> ==5612==by 0xA3855C: zend_register_standard_constants
>> (zend_constants.c:116)
>> ==5612==by 0xA52D6E: zend_startup (zend.c:671)
>> ==5612==by 0x9C7FAA: php_module_startup (main.c:2099)
>> ==5612==by 0xAFA460: php_cli_startup (php_cli.c:421)
>> ==5612==by 0xAFC4D6: main (php_cli.c:1335)
>> ==5612==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
>>
>> And jump.php is:
>>
>> > $a = 1;
>> switch($a) {
>> case 0: echo 0; break;
>> case 1: echo 1; break;
>> case 2: echo 1; break;
>> case 3: echo 1; break;
>> case 4: echo 1; break;
>> case 5: echo 1; break;
>> case 6: echo 1; break;
>> case 7: echo 1; break;
>> case 8: echo 1; break;
>> case 9: echo 1; break;
>> }
>>
>> -Rasmus
> 
> Hey,
> 
> this doesn't really look related to my patch. Did you do something wrong
> when cloning my branch? Or forget a make clean or similar?
> 
> Locally it works for me and echoes 1 as expected.

Ah, looks like you are right. A full distclean cleared it up. I had just
done a distclean, but I had built once before applying your patch.
Crappy Makefile deps..

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Reviving scalar type hints

[Rasmus Lerdorf]

On 02/16/2015 03:58 PM, Sara Golemon wrote:
> On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre  wrote:
>> Once again, anyone can take over version 0.3, if it is so great. Why don't 
>> you do it ?
>> I will play the game, stop working on my proposal, and vote 'yes' again.
>> But don't ask me to do it in your place.
>>
> If nobody else does it, I will.
> 
> I think Andrea's 0.3 proposal was extremely well balanced, served
> everyone's needs whether they would admit it or not, and who's only
> failing (subjectively termed) was the use of declare().  I think
> declare() is fine and not nearly as ugly as some have slandered it to
> be, but I'm willing to read the winds and modify it for v0.4.

I still disagree strongly that it serves everyone's needs. The internal
API and APIs provided by extensions are completely messed up by this
approach. Userspace authors get the choice when they write their code.
Even if the caller has turned on strict, if you haven't added strict
types to your functions/methods you are fine. Internal API and extension
authors don't get this luxury. If the caller turns on strict, then
suddenly an API that was written explicitly to make use of the coercive
characteristics PHP has had for 20+ years breaks and there is nothing I
can do about it as an extension author. This is beyond just int->float
coercion, which is, of course, also missing.

A simple example:

number_format($num);

So, for various inputs without strict enabled:

int(1000)
1,000

string(4) "1000"
1,000

float(1000)
1,000

string(5) "1000 "
Notice: A non well formed numeric value encountered in ...
1,000

string(5) " 1000"
1,000

string(9) "1000 dogs"
Notice: A non well formed numeric value encountered in ...
1,000

string(3) "dog"
Warning: number_format() expects parameter 1 to be float, string given
NULL

resource(5) of type (stream)
Warning: number_format() expects parameter 1 to be float, resource given
NULL

This is the intended API. The function does some sanity checking for
things that clearly don't make sense based on what it was written to do
and fails hard. It also lets the user know about questionable data and
relies on coercion for the rest. You could argue that the "1000 dogs"
case should be more severe than a notice, but that is pretty minor I
think. The extension author has the ability to make that more severe if
she likes.


Now turn on strict and we get:

int(1000)
number_format() expects parameter 1 to be float, integer given

string(4) "1000"
number_format() expects parameter 1 to be float, string given

float(1000)
1,000

string(5) "1000 "
number_format() expects parameter 1 to be float, string given

string(5) " 1000"
number_format() expects parameter 1 to be float, string given

string(9) "1000 dogs"
number_format() expects parameter 1 to be float, string given

string(3) "dog"
number_format() expects parameter 1 to be float, string given

resource(5) of type (stream)
number_format() expects parameter 1 to be float, resource given

That in itself might not be so terrible, but also not terribly useful
and it is nothing like what the extension author had intended. And how
do you think users will deal with internal functions that are now
suddenly strongly typed even though they were not designed to be? Do you
think they will go look at the source code for the function and mimic
the data sanity checks and put those in their userspace code? Doubtful,
and as people on irc and everywhere have told me, they will just cast.
No big deal. So, we run the same set of data through with strict enabled
and doing a number_format((float)$num):

int(1000)
1,000

string(4) "1000"
1,000

float(1000)
1,000

string(5) "1000 "
1,000

string(5) " 1000"
1,000

string(9) "1000 dogs"
1,000

string(3) "dog"
0

resource(5) of type (stream)
5


Out of the 3 scenarios, this is inarguably the worst outcome with the
last line there being the most blatant. Actually outputting an internal
resource id as if it was a valid number to be formatted without the
slightest notice or warning anywhere that something is wrong in the code.

This is my fear with this approach. People will start littering their
code with casts and it will hide real bugs which is the complete
opposite of what motivated this in the first place.

Without more thought into how we properly deal with internal/extension
code I don't really understand how so many people foresee this to work
perfectly in the real world.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Reviving scalar type hints

[Rasmus Lerdorf]

On 02/16/2015 05:57 PM, Sara Golemon wrote:
> On Mon, Feb 16, 2015 at 4:52 PM, Rasmus Lerdorf  wrote:
>> I still disagree strongly that it serves everyone's needs. The internal
>> API and APIs provided by extensions are completely messed up by this
>> approach. Userspace authors get the choice when they write their code.
>> Even if the caller has turned on strict, if you haven't added strict
>> types to your functions/methods you are fine. Internal API and extension
>> authors don't get this luxury. If the caller turns on strict, then
>> suddenly an API that was written explicitly to make use of the coercive
>> characteristics PHP has had for 20+ years breaks and there is nothing I
>> can do about it as an extension author. This is beyond just int->float
>> coercion, which is, of course, also missing.
>>
> It's not your problem how a script author choses to use your function.

I would very much like it to be my problem how my API is exposed to a
user. At the very least I should have as much control over an API
written in C as one written in PHP. Currently with this RFC it is not
the case and worse, it is retroactively changing an existing set of
functions to be all-strict when this mode is turned on. Even with strict
mode enabled, userspace is not retroactively turned strict and you can
slowly transition your API to be strict by adding appropriate strict
types in a controlled fashion.

And this fact is quickly glossed over to the point where I believe a lot
of people didn't even realize that they were voting for a retroactive
all-strict internal API. But hopefully I am wrong on that point.

> We can sigh and tut about this not being "the PHP way", but the script
> author was the one who chose to enter into a tight contract, and the
> script author, not you, is the one who should have that authority over
> their own application.

I find this view way too extreme. Not everything is this black and white
in the real world. We have to be really careful that we don't give the
illusion of better while we make things worse for people. In the real
world, you know for a fact that people are going to force-cast stuff and
they aren't necessarily going to be very careful about it.

The illusion being strict is better than weak-coercive, so let's turn on
strict everywhere. Oh, damn, some stuff broke. Throw in some casts,
things work and hey we are now safer because we are strict. Where in
reality "strict+force cast" tends to be worse than "weak coercive" as
per the number_format((float)"dog") example.

>> And how do you think users will deal with internal functions that are now
>> suddenly strongly typed even though they were not designed to be?
>>
> I think they'll deal with it by dint of having /chosen/ to turn on
> strict typing.  It's not as though an upgrade to PHP 7.12 suddenly
> made all their code strict without warning.  In fact, nothing will
> have changed for them at all UNLESS THEY EXPLICITLY ASK FOR IT.

Right, but they will want to start using strict, or else what are we
even talking about? And as soon as they do that string that comes back
from their ORM and passed to number_format() now needs to be dealt with
somehow. I'll bet you a Tim Horton's doughnut that a depressingly high
percentage of people will simply toss a (float) cast on it and move on
and by doing so they have made their application worse.

> Again, you're assuming a single method call in a vacuum.  Is it
> possible that the kind of script author who is turning on strict
> typing might, in fact, be strict in the rest of their application?
> Might, in fact, not try to pass a resource into a function expecting
> float because they have the tools of strict typing available to them?

That's a lot of assumptions. Library functions get data from all sorts
of edges that are outside of the scope of simple type checking on
function arguments. I'd rather not encourage incorrect behaviour here by
retroactively changing the API like that.

> So let's talk compromise.
> Would leaving internal functions out of the picture at this stage
> change you mind?  This is effectively what Hack does, internal
> functions are explicitly marked as "coercible".
> Would a tri-state option make sense? ('weak-all',
> 'strict-user/weak-internal', 'strict-all')
> How do we get from here to something you would like?

So in Hack you didn't think it was a good idea to change the internal
and extension api either? Was the reasoning similar to mine? Did you
agree with the reason then but not now?

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Reviving scalar type hints

[Rasmus Lerdorf]

On 02/16/2015 09:48 PM, Sara Golemon wrote:
> Second, I should clarify that while the HHVM runtime performs
> coersion, the hack type checker is strict.  So my original statement
> was inaccurate.  As far as hack is concerned, it's simply strict.
> Period.

With both the default (partial) type checking and strict enabled, my
number_format() example in Hack produces:

int(1000)
1,000

string(4) "1000"
1,000

float(1000)
1,000

string(5) "1000 "
Warning: number_format() expects parameter 1 to be double, string given

string(5) " 1000"
1,000

string(9) "1000 dogs"
Warning: number_format() expects parameter 1 to be double, string given

string(3) "dog"
Warning: number_format() expects parameter 1 to be double, string given

resource(4) of type (stream)
Warning: number_format() expects parameter 1 to be double, resource given


Basically it accepts, ints, floats and well-formed numeric strings and
the hh_client type checker is telling me I have "No errors". So the only
difference between Hack's strict mode and the current coercive behaviour
in PHP is strings with trailing chars. The "1000 dogs" case. "1000 " as
well in my example, but that is the same case. Where in PHP you get a
notice but it still does the conversion and in Hack you get a warning
and the conversion isn't done. So even though Hack has both a "partial"
type checking mode and a "strict" mode, the decision was to still do
type coercion for the others. I kind of expected it to only accept a
float in full-on strict mode to mimic the no-compromise strictness
proposed in the RFC.

Also, looking through the code, I really don't see this "simply strict"
anywhere when it comes to calling internal functions. For example:

$a = [1,2,3,4,5];
print_r(array_reverse($a,"0"));

It doesn't complain that "0" is a string and not a boolean. It doesn't
even complain about "dog" there.

And the one everyone gets uppity about. bool->int conversion in
curl_setopt(). eg.

$ch = curl_init("https://74.125.28.104";);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
echo curl_exec($ch);
echo curl_error($ch);

PHP obviously converts true to 1 there which has been a problem because
what people really meant was to set it to 2. We spew a notice for this,
of course:

Notice: curl_setopt(): CURLOPT_SSL_VERIFYHOST with value 1 is deprecated
and will be removed as of libcurl 7.28.1. It is recommended to use value
2 instead in ...

In Hack it appears that true is also converted to 1 in https://74.125.28.104";);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, ["I have no idea what I am
doing"]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
echo curl_exec($ch);
echo curl_error($ch);
return "beer";
}

hh_client reports:
/home/rasmus/test/a.php:8:12,17: Invalid return type (Typing[4110])
  /home/rasmus/test/a.php:2:19,21: This is an int
  /home/rasmus/test/a.php:8:12,17: It is incompatible with a string

When I change return "beer" to return 1 hh_client is happy.

So, you keep asking what I would support. I would like to see an RFC
along the following lines:

1. Tighten up the type coercion for the "1000 dogs" case although we
   have to look at whether there is a problem with some database APIs
   returning space-padded fields so "1000" would now break.
   Hopefully that is fringe enough to not break the world.

2a. In strict mode, tone down the strictness and allow non-lossy
coercion including int->float. And yes, I know in really edge cases
that isn't technically non-lossy, but for all practical purposes it
is.

or

2b. A much more flexible system for specifying multiple types. I should
be able to say that my function takes something that looks like a
number if I choose and still take advantage of stricter typing for
other parameters.

3. Don't turn on crazy-strict mode for internal functions that weren't
   designed for that. Instead provide the same ability as userspace gets
   for developers to gradually design their APIs to be stricter if they
   so desire allowing both Hack and PHP to implement a stricter
   curl_setopt(), for example.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Reviving scalar type hints

[Rasmus Lerdorf]

On 02/17/2015 01:11 AM, Benjamin Eberlei wrote:
> I think curl_setopt is a misleading example in the typehinting
> discussion, because
> this kind of API does not benefit from it. The third argument depends
> on the second argument and requires a "generic" type in code:
> 
> curl_setopt(resource $ch, int $option, mixed $data);
> 
> It won't be possible to change this (or any similar API) with strict
> type hints. 
> 
> The code to convert a boolean $data to integer in the VERIFYPEER case is
> manually
> implemented and therefore subject to the implementors design decisions.

Sure, I realize this, but it is the bool->int coercion example that is
always brought up. A static analysis type checker would have trouble
catching this, but both PHP and Hack apply that coercion at runtime:

   case CURLOPT_SSL_VERIFYHOST:
   if(Z_BVAL_PP(zvalue) == 1) {

The runtime could say, hey, I am in strict mode here and you are passing
me an array of strings which I am coercing to a boolean. Not cool.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Reviving scalar type hints

[Rasmus Lerdorf]

On 02/17/2015 08:38 AM, Sara Golemon wrote:
> On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf  wrote:
>> Please correct me here if I somehow ran these incorrectly. I did put
>> some deliberate type errors into my userspace code and hh_client caught
>> those nicely, so it seems like it was working, but it didn't catch
>> anything when it came to calling the internal API functions.
>>
> The mechanisms are strict, but the definitions, in hack, are untyped,
> so there's nothing to validate:
> 
> hphp/hack/hhi/stdlib/builtins_string.hhi:
>   function number_format($number, $decimals = 0, $dec_point = ".",
> $thousands_sep = ",");

Right, so most of the internal API functions were omitted from strict
typing in Hack it looks like except for some places where it made sense
to selectively apply stricter checks. The RFC as it stands doesn't give
us this option which is my major problem with it.

> Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode?
> Or something passed to the arg_info struct? The details are secondary,
> but you get my meaning...

Yes, something along those lines to allow gradual and selective strictness.

The internal/extension api is just another library and the authors of
these library functions should have the same allowance as userspace
library authors. Like you said in one reply, "What's yours is yours,
what's theirs is theirs."

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Scalar Type Hints v0.4

[Rasmus Lerdorf]

On 02/17/2015 04:35 PM, Nikita Popov wrote:
> I don't buy into Rasmus arguments about internal functions. They concern
> one particular edge case (int->float coercion) and I doubt they have much
> relevance if applied to codebases with pervasive use of typehints (where
> you can be reasonably sure of the types of your variables). Even if, for
> the sake of argument, we acknowledge the concern as valid we should be
> discussing that particular case (int->float coercion) rather than dropping
> the strict typing for internal functions altogether.

int->float is actually secondary to "123"->int. And while they may be
edge-cases there are enough of them that we would be pushing people
towards casting by default which should be a last-resort thing, not the
first thing you do.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Scalar Type Hints v0.4

[Rasmus Lerdorf]

On 02/18/2015 08:51 AM, François Laupretre wrote:
>> De : Pádraic Brady [mailto:padraic.br...@gmail.com]
>>
>> Careful, it helps not to call folk "radicals" if you intend to pursue
>> a compromise with them ;).
> 
> Sorry, english is not my native language, and 'radical' may be offensive.
> 
> I was just looking for a word for people who consider providing two modes is 
> a pre-requisite to any discussion.
> 
>> I wouldn't necessarily mind int->float - it's lossless assuming one way only.
> 
> It's lossless but it kills the 'strict' position. It can be claimed, one hand 
> on the heart, this will be the only exception but, as use cases and side 
> effects accumulate, we all know it will finish as a bunch of exceptions to a 
> no-more strict mode, adding confusion where it is not needed. I guess the 
> next one would be (int -> bool), and the rest would follow.

We need to keep in mind that int->float isn't technically lossless. We
have a 53-bit IEEE754 mantissa to take account for here, so it is only
lossless for values below 36028797018963966 or so.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Digit separators for numeric literals

[Rasmus Lerdorf]

On 02/18/2015 06:07 PM, Christoph Becker wrote:
> Hi internals!
> 
> A while ago a question was asked on the php-general mailing list with
> regard to digit seperators in numeric literals[1].
> 
> IMHO it might be a useful enhancement to allow such digit separators for
> numeric (integer and float) literals in PHP for better readability;
> several other languages already support them (such as Java, Perl, Ruby,
> C#, Eiffel and C++14).
> 
> Before attempting to draft a respective RFC, I'd like to get some
> feedback, whether this is generally considered to be useful, which
> character would be preferred (most other languages seem to allow the
> underscore, but an apostroph or maybe some other character might be
> reasonable as well), and which restrictions should be applied (e.g.
> arbitrary use of the separator, group thousands only, etc.)
> 
> I'm looking forward to hear your opinion.  Thanks in advance.
> 
> [1] 

I think it will be difficult to find a separator character that doesn't
make a mess of the grammar.

  my_func(1,999,999) obviously doesn't work
  my_func(1'999'999) as per C++14 clashes with our single-quoted strings
  my_func(1_999_999) like in ADA might work

but _999_ would need to work as well and _ is a valid char in a constant
so you can have a constant named _999_.

  - nope
  # nope
  @ nope
  ~ nope
  ! nope
  % nope
  ^ nope

We went through this for the namespace char, and there simply isn't a
typable single character left to use for something like this. _ is the
closest but it would require some changes and BC breaks which I am not
sure is worth for what appears to me to be a not-so critical feature.

Now if we went into Unicode territory, we could do it. eg.

  my_func(1 999 999) U+1680 (although it looks too much like a -)
  my_func(1 999 999) U+205F (mathematical space)
  my_func(1٬999٬999) U+066C (Arabic thousands separator)
  my_func(1·999·999) U+00B7 (middle dot)

The last one looks best to me, but we'd need a team of people working in
shifts to answer the, "How do I type this?" question.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Digit separators for numeric literals

[Rasmus Lerdorf]

On 02/18/2015 11:21 PM, Rick Widmer wrote:
> On 2/18/2015 7:44 PM, Rasmus Lerdorf wrote:
>> Now if we went into Unicode territory, we could do it. eg.
>>
>>my_func(1 999 999) U+1680 (although it looks too much like a -)
>>my_func(1 999 999) U+205F (mathematical space)
>>my_func(1٬999٬999) U+066C (Arabic thousands separator)
>>my_func(1·999·999) U+00B7 (middle dot)
>>
>> The last one looks best to me, but we'd need a team of people working in
>> shifts to answer the, "How do I type this?" question.
>>
>> -Rasmus
> 
> how about:
> 
> my_func( '1,000.04' );   //if you want to use separators there.

The problem with that is that the world is split. The other half, or
actually more than half, would write that as '1.000,04'. There is no way
we would want to take sides on that one. And we have support for
locale-based number formatting and parsing via numfmt_format() and
numfmt_parse(). If we were going to add a separator for literals, the
only real low-ascii choice is _ which is also used by Ada, D, Java, Perl
and Ruby.

I was 90% kidding about using a Unicode character, but if you think
about it a bit, most people are using IDEs or at least smart scriptable
editors, it wouldn't be that much of a stretch to picture your editor
pretty-printing 1234567890 as 1·234·567·890 or 1˙234˙567˙890 (U+02D9).
It would be easy to make the parser ignore that character in numeric
literals. Much easier than working out the various issues with _ anyway.

Although, personally it would freak me out if my editor started messing
with my numbers on me. But I don't use an IDE. I don't even have
syntax-highlighting turned on in my vim config. We didn't have stuff
like that on the Wyse 50.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Digit separators for numeric literals

[Rasmus Lerdorf]

On 02/18/2015 11:49 PM, Michael Wallner wrote:
> On 19/02/15 03:44, Rasmus Lerdorf wrote:
> 
>> but _999_ would need to work as well and _ is a valid char in a constant
>> so you can have a constant named _999_.
>>
> 
> Why would we need to support the underscore in front (and maybe even at
> the end) of a number?

I guess we could restrict it to not be leading. I was thinking along the
lines of the character being defined to be ignored anywhere in a
literal. The underscore was actually rejected in C++14 because C++ has
user defined literals.

  http://en.cppreference.com/w/cpp/language/user_literal

which would then make 0x12_ab problematic. We obviously don't have
user-defined literals so we probably could make it work. Like I said,
that is the only viable option as far as I can see.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Reviving scalar type hints

[Rasmus Lerdorf]

On 02/20/2015 09:39 AM, Anthony Ferrara wrote:
> I think if anything, the appearance of Hack (and its adoption) show
> that people want static typing, at least to some level...

To be perfectly transparent here though, you should mention that your
proposed RFC goes well beyond the strict typing that is in Hack because
in Hack the internal API is largely untyped while your proposal is to
default the entire internal API to strict types in strict mode. Also, in
Hack there is a distinction between the off-line hh_client type-checker
and the runtime.

Hack examples all using 

signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Reviving scalar type hints

[Rasmus Lerdorf]

On 02/20/2015 10:52 AM, Josh Watzman wrote:
> On Feb 20, 2015, at 10:30 AM, Rasmus Lerdorf  wrote:
>> Hack examples all using >
>>  echo number_format('1000');
>>  echo htmlspecialchars(1000);
>>  echo md5(1000);
>>
>> These are all fine both as far as the type-checker is concerned as well
>> as the runtime, of course, but they are runtime fatals in your proposed RFC.\
> 
> And they should be errors in Hack too. The reason they aren't are to ease 
> transitions from PHP to Hack. I'd expect them to be more strongly typed 
> eventually.

Right, you are doing a gradual transition of an API that wasn't written
to be strict. It was written with the assumption that type coercion
would take place. If there is a good reason to ease the transition from
PHP to Hack there is an even stronger reason to ease the transition from
PHP to PHP.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] A different user perspective on scalar type declarations

[Rasmus Lerdorf]

On 02/26/2015 10:49 AM, Dan Ackroyd wrote:
> In most applications, the part of the code that is exposed to the
> outside world and has to convert strings or unknown types into known
> types is a very small layer at the outside edge of the application.
> 
> The vast majority of code written for non-trivial applications has no
> contact with the outside world. Instead it only communicates to other
> layers inside the application where the types required are fully
> known, and so the parameters passed should already be in the correct
> type. And so type coercion is at best unneeded, and usually not
> wanted.

Looking through some very large code bases I am involved with this
argument falls down on two main points:

1. There is a lot of data coming from memcache/mysql/pgsql as strings
that is not typed.

2. There are quite a few objects being shuffled around interchangeably
with strings and making use __toString magic.

Type coercion is needed in both cases here. This is in the backend code
far for user input. It would take a whole lot of refactoring to be able
to turn on strict for this code. Especially getting rid of all use of
__toString objects. It would require force-casts to make this backend
code work in strict mode and then we are back to square one.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Consistent function names

[Rasmus Lerdorf]

On 03/02/2015 03:54 PM, Yasuo Ohgaki wrote:
> Hi Markus, Larry and Rowan,
> 
> On Tue, Mar 3, 2015 at 8:36 AM, Markus Fischer  wrote:
> 
>> On 03.03.15 00:10, Yasuo Ohgaki wrote:
>>> I would love to have new & clean APIs.
>>>
>>> Please think my proposal as legacy API cleanups. Many of candidates will
>>> remain
>>> without CORDING_STANDARSDS confirmed names almost forever. This is what
>>> I would like to improve. If you don't care about legacy stuff cleanups,
>>> please don't
>>> care. The cleanups will not hurt anything, almost.
>>
>> No ill intentions here, but adding the aliases and, as you propose,
>> literally adding *hundreds* of aliases is actually a mess to me.
>>
>> What you call "new & clean" is as a shield for effectively introducing
>> duplicates. You do not clean up anything that way. You leave a even
>> bigger mess behind. By going for your honorable goal of correcting
>> things I think you got lost in the woods.
>>
>> IMHO the only forward is to make sure new/future additions to the
>> language adhere to the coding standard or use a smart way (i.e. the
>> scalar addition).
> 
> 
> I think I understand your point very well.
> However, I have an urge impulse to add standard confirmed names
> when I see manual pages like
> 
> http://php.net/manual/en/book.gettext.php
> bind_textdomain_codeset — Specify the character encoding in which the
> messages from the DOMAIN message catalog will be returned
> bindtextdomain — Sets the path for a domain
> dcgettext — Overrides the domain for a single lookup
> dcngettext — Plural version of dcgettext
> dgettext — Override the current domain
> dngettext — Plural version of dgettext
> gettext — Lookup a message in the current domain
> ngettext — Plural version of gettext
> textdomain — Sets the default domain
> 
> This looks awful... just cannot put up with...

These come from the underlying libaries. You can type "man dcgettext" or
"man bind_textdomain_codeset" at your Linux command line and learn a lot
about how these work. Plus, if you are a C dev, much like strlen(),
these are simply the names you expect, or at least they are instantly
recognizable to you. As I normally explain to people, there is vertical
consistency here, not horizontal consistency.

I understand how people who don't have a background in the underlying
libraries might wish for a different API and horizontal consistency
across disparate extensions, but simply adding a bunch of aliases that
have no basis in anything doesn't help anybody.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Consistent function names

[Rasmus Lerdorf]

On 03/03/2015 07:34 PM, Yasuo Ohgaki wrote:
> Hi Michael,
> 
> On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett 
> wrote:
> 
>> Your evaluation is pretty anecdotal. I agree with some points but you need
>> some solid evidence if you are going to rate these languages. Also do you
>> have a list of all the functions you would like to rename or is this a
>> sweeping lets just change everything so it matches and deprecate all the
>> old stuff. Your matrix is a very weak push to do so. If you want to make
>> these changes it would be better to choose a select set such as the array
>> functions and try and push that through or see what that change might look
>> like and if it's really beneficial to userland.
> 
> 
> I agree that my evaluation is subjective. For example, I rate PHP has "1"
> security only
> because PHP is very weak against script/file inclusions because it's fatal
> and other
> languages apps do not have script/file inclusions as PHP apps do. Others
> might
> rate "2" or even "3" because it is too easy to fix it even if incident is
> fatal.
> (Security should be evaluated by "how difficult to make mistakes", not "how
> easy to
> fix mistakes" generally. IMHO)
> 
> I made list of rename candidates
> https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
> If you have suggestions, I appreciate!

Yasuo, please stop. This isn't going to happen. Changing strlen() to
str_len() is just ridiculous.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Consistent function names

[Rasmus Lerdorf]

On 03/04/2015 08:26 AM, guilhermebla...@gmail.com wrote:
> @Rasmus:
> 
> I don't see what's the problem of aliasing functions for the next 1-2
> majors, deprecate the inconsistent one in the following and remove later.

As far as I am concerned str_len() would be the inconsistent one. Like I
explained previously, these function names for the most part, aren't
ones I made up. They come from the underlying libraries and whether you
personally value that or not, there is an actual reason for their names.
Many of them are iconic entities on their own, at least to people with
experience outside of PHP. Terms like "recvfrom", "getenv" and yes,
"strlen" are well-established names that should not be split up into
"recv_from", "get_env" and "str_len" due to some sort of arbitrary
consistency/purity idea any more than I should have my name changed to
Ras_mus.

As many people have already suggested in this thread, if we are going to
do something here it has to bring actual value and can't just be a bunch
of aliases littering the global namespace further.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Consistent function names

[Rasmus Lerdorf]

On 03/04/2015 08:25 PM, Yasuo Ohgaki wrote:
> Hi Rasmus,
> 
> On Thu, Mar 5, 2015 at 1:46 AM, Rasmus Lerdorf  <mailto:ras...@lerdorf.com>> wrote:
> 
> On 03/04/2015 08:26 AM, guilhermebla...@gmail.com
> <mailto:guilhermebla...@gmail.com> wrote:
> > @Rasmus:
> >
> > I don't see what's the problem of aliasing functions for the next 1-2
> > majors, deprecate the inconsistent one in the following and remove 
> later.
> 
> As far as I am concerned str_len() would be the inconsistent one. Like I
> explained previously, these function names for the most part, aren't
> ones I made up. They come from the underlying libraries and whether you
> personally value that or not, there is an actual reason for their names.
> Many of them are iconic entities on their own, at least to people with
> experience outside of PHP. Terms like "recvfrom", "getenv" and yes,
> "strlen" are well-established names that should not be split up into
> "recv_from", "get_env" and "str_len" due to some sort of arbitrary
> consistency/purity idea any more than I should have my name changed to
> Ras_mus.
> 
> As many people have already suggested in this thread, if we are going to
> do something here it has to bring actual value and can't just be a bunch
> of aliases littering the global namespace further.
> 
> 
> I have mixed feeling for well established names indeed.
> These function names are debatable. Latest RFC leaves fopen()/fread()/etc
> as it is now, for example.
> 
> https://wiki.php.net/rfc/consistent_function_names#file_related_functions
> 
> Personally, I don't mind to keep current names for strlen()/etc. 
> You don't mind at all to have php_version()/etc probably. It's possible to 
> have separate vote for names that are debatable or even keep current
> names without vote.
> 
> If you could provide list of debatable names, I'll have separate votes
> for them
> or keep current names without vote.

Every function name defined by IEEE Std 1003.1 along with the arguments
and argument order would be on that list. When we have procedural
functions that are either thin wrappers around or otherwise behave
identically to an IEEE 1003.1 defined function, then the name and
arguments currently match that specification quite well. Any deviation
should have a really really good reason.

You can find the full list here:

http://pubs.opengroup.org/onlinepubs/9699919799/idx/is.html

Click on the letters at the top for functions starting with the other
letters.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Consistent function names

[Rasmus Lerdorf]

On 03/04/2015 10:21 PM, Yasuo Ohgaki wrote:
> The same could be done for new names.
> Manual pages for localtime()/mktime()/etc would look a lot nicer. 
> I hope there will be more favored developers with the RFC. Since I'm
> going to
> update manual to have alias search feature, developers used to POSIX can
> find
> PHP function name easily. If they would like to use POSIX name, they can use
> it also. Nobody will try to remove POSIX names in the future, I suppose.
> 
> In short, I would like to propose to have both PHP and IEEE names as
> officially
> valid names. Do you like this proposal?

Nope, I don't. PHP is over 20 years old at this point and the PHP names
for the functions are one and the same as the IEEE names. I see
absolutely no reason to create a new class of "PHP" names.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Is OpCache enabled by default in php 5.5 and later or not?

[Rasmus Lerdorf]

On 03/05/2015 08:12 AM, j adams wrote:
> I don't know if this is a question for the documentation team or not, but
> figured I'd start here. There does not appear to be any definitive, clear,
> reliable information on PHP's op caching functionality in recent 5.*
> versions and this problem needs to be remedied.
> 
> Question 1: Is OpCache enabled by default in php 5.5 and later or not?
> 
> This page:
> http://php.net/manual/en/intro.opcache.php
> says "This extension is bundled with PHP 5.5.0 and later, and is »
> available in PECL for PHP versions 5.2, 5.3 and 5.4."
> 
> But this page:
> http://php.net/manual/en/opcache.installation.php
> says "PHP 5.5.0 and later
> 
> OPcache can only be compiled as a shared extension. If you have disabled
> the building of default extensions with --disable-all , you must compile
> PHP with the --enable-opcache option for OPcache to be available.
> 
> Once compiled, you can use the zend_extension configuration directive to
> load the OPcache extension into PHP. This can be done with
> zend_extension=/full/path/to/opcache.so on non-Windows platforms, and
> zend_extension=C:\path\to\php_opcache.dll on Windows."
> 
> 
> 
> Question 2:
> If OpCache is enabled, does it require any php.ini settings or not? Does it
> show any functions or constants or phpinfo() that will reveal its
> existence?  I've got php 5.6.6 installed on CentOS 7 and I can find neither
> hide nor hair of it.  There is, however, an opcache package one can install
> (php56u-opcache.x86_64 in my case).
> 
> 
> 
> Question 3:
> What about Zend Optimizer? Still other articles say it has been integrated
> into php 5.5 and later, but this mythical beast also makes no sign to
> indicate its inclusion either. Some articles:
> https://wiki.php.net/rfc/optimizerplus
> https://wordpress.org/support/topic/looking-ahead-to-php-55-zend-optimizer-the-end-of-apc
> http://www.internetnews.com/blog/skerner/php-5-5-to-include-open-source-zend-optimizer-.html

Opcache is bundled with PHP as of PHP 5.5, but distros like to unbundle
things and provide them as separate packages. We can't do much about
that and it is also hard to document all the variations distros come up
with. So yes, in your case you need to install the opcache package.
Presumably the way Centos has created the rpm it will add the
appropriate magic ini settings and you will see opcache listed in your
phpinfo() output after installing that package.

And ZendOptimizer is the same as Opcache in this context.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

[Rasmus Lerdorf]

On Mar 14, 2015, at 13:37, Levi Morrison  wrote:
> It seems that `float -> bool` is always disallowed. If I am correct
> `int -> bool` is permitted for all values (not just 0 and 1), which
> means that floats which can be converted to integers without dataloss
> should also be permitted to be booleans. If a specific float can be
> converted to an int, and all ints can be converted to booleans, then
> the transitive property should hold for that float to a bool.

The problem there is what does "without dataloss" mean? At which precision do 
you consider there to be no dataloss? 

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7

[Rasmus Lerdorf]

On 03/15/2015 07:31 AM, Philip Sturgeon wrote:
> On Sat, Mar 14, 2015 at 7:38 AM, Bob Weinand  wrote:
>>> Am 14.03.2015 um 10:21 schrieb Pavel Kouřil :
>>>
>>> On Saturday, March 14, 2015, Levi Morrison  wrote:
 RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7

 The proposal has changed from the original. It no longer reserves the
 aliases out of the interest of reserving the smallest useful,
 uncontroversial subset. Some people want to remove aliases for these
 types so in the interest of being as uncontroversial as possible I am
 no longer proposing to remove them.

 This will go into voting on March 15th unless something comes up
 between now and then to persuade me otherwise.

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


>>>
>>> Hello,
>>>
>>> why do you consider a "true" and "false" as a type? It's not a type. it's a
>>> value?
>>>
>>> Regards
>>> Pavel Kouril
>>
>> These aren't types. But useful for e.g. union types (int|false). [By the way 
>> they're internally handled as different types… but that's an implementation 
>> detail…]
>>
>> Also, he doesn't call them anywhere types, it's just the title.
>>
>> Bob
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
> 
> This is a solid plan. Vote this and everyone should +1 it, so if this
> scalar squabble results in a a 0-0-0 score we can at least add scalars
> later.

This is not quite that obvious I don't think. If
https://wiki.php.net/rfc/context_sensitive_lexer isn't ready in time for
7.0 and we don't need to reserve these for one of the STH RFCs then we
should hold off and do it alongside the context sensitive lexer change
or we are going to needlessly break a ton of code including Drupal8:


https://github.com/drupal/drupal/blob/8.0.x/core/lib/Drupal/Component/Utility/String.php#L15

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7

[Rasmus Lerdorf]

On 03/15/2015 09:41 AM, Niklas Keller wrote:
> Rasmus, the context sensitive lexer doesn't change anything for Drupal.
> Support for class names has been dropped,
> see https://wiki.php.net/rfc/context_sensitive_lexer#rejected_features

Yes, I realize that. I just mentioned Drupal as an example of a major
codebase that will break as soon as we reserve "string". The context
sensitive lexer change will help minimize other types of breakages from
adding these reserved words, so I still think introducing them at them
same time makes sense.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c

[Rasmus Lerdorf]

> Diff:
> diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
> index 16f2d5f..e12b00d 100644
> --- a/Zend/Zend.m4
> +++ b/Zend/Zend.m4
> @@ -409,3 +409,48 @@ else
>  AC_MSG_RESULT(no)
>fi
>  fi
> +
> +AC_ARG_ENABLE(gcc-global-regs,
> +[  --disable-gcc-global-regs
> +  whether to enable GCC global register
> variables],[
> +  ZEND_GCC_GLOBAL_REGS=$enableval
> +],[
> +  ZEND_GCC_GLOBAL_REGS=yes
> +])
> +AC_MSG_CHECKING(for global register variables support)
> +if test "$ZEND_GCC_GLOBAL_REGS" != "no"; then
> +  AC_TRY_COMPILE([
> +  ],[
> +#if defined(__GNUC__) && defined(i386)
> +# define ZEND_VM_FP_GLOBAL_REG "%esi"
> +# define ZEND_VM_IP_GLOBAL_REG "%edi"
> +#elif defined(__GNUC__) && defined(__x86_64__)
> +# define ZEND_VM_FP_GLOBAL_REG "%r14"
> +# define ZEND_VM_IP_GLOBAL_REG "%r15"
> +#else
> +# error "global register variables are not supported"
> +#endif
> +typedef int (*opcode_handler_t)(void);
> +register void *FP  __asm__(ZEND_VM_FP_GLOBAL_REG);
> +register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
> +int emu(const opcode_handler_t *ip, void *fp) {
> +   const opcode_handler_t *orig_ip = IP;
> +   void *orig_fp = FP;
> +   IP = ip;
> +   FP = fp;
> +   while ((*ip)());
> +   FP = orig_fp;
> +   IP = orig_ip;
> +}
> +  ], [
> +ZEND_GCC_GLOBAL_REGS=yes
> +  ], [
> +ZEND_GCC_GLOBAL_REGS=no
> +  ])
> +fi
> +if test "$ZEND_GCC_GLOBAL_REGS" = "yes"; then
> +  AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system has
> support for global register variables])
> +else
> +  HAVE_GCC_GLOBAL_REGS=no
> +fi
> +AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS)

Dmitry, the perf boost of this is awesome, but is it completely safe?
Won't a signal potentially overwrite a register variable here? Like on a
timeout, for example?

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?

[Rasmus Lerdorf]

On 03/19/2015 01:26 PM, Eric Stenson wrote:
> PHP Internals folks--
> 
> We're doing some performance work in WinCache, and we're finding that some 
> frameworks are...uh...enthusiastically using file_exists(), is_file() and 
> is_dir() functions on files/directories that don't exist.  Every. Single. 
> Pageload.
> 
> Does the PHP stat cache include negative cache entries?  If not, why not?
> 
> Are there any existing extensions that implement a negative cache for 
> file_exists(), is_file(), et. al.?

We do not do negative caching. This is documented at
http://php.net/manual/en/function.clearstatcache.php where it says:

  You should also note that PHP doesn't cache information about
  non-existent files. So, if you call file_exists() on a file that
  doesn't exist, it will return FALSE until you create the file. If you
  create the file, it will return TRUE even if you then delete the
  file. However unlink() clears the cache automatically.

But, I think you are also missing the fact that the stat cache is
per-request. So your "every single pageload" aspect won't be helped by
adding negative caching to the stat cache. It is still going to stat on
every single page load. It is only multiple identical stats within the
same request that gets caught by the stat cache.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Proposal to delay 7.0 timeline

[Rasmus Lerdorf]

On 03/21/2015 08:52 AM, François Laupretre wrote:
> Now, after more calls from many of you to delay it, and as Zeev himself
> seemed to consider it as more acceptable, I am proposing again to delay 7.0
> feature freeze to May, 15 (2 month delay, date where vote is starting). I
> won’t repeat all the arguments of my previous posts but, to summarize, it
> would allow to include important features, making it a ‘real’ major version.
> Releasing a major version is not just a question of BC break, we also need
> to think about what we put forward. So, we need features. We already have
> STH, but we can do more (I personally have at least 4 RFCs I didn’t have
> time for, including scalar pseudo-methods, which can be an important
> feature).

No, please, let's get what we have stabilized and out the door. There
are always more things to do and we can delay things indefinitely. And I
completely disagree that this isn't a 'real' major version.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Use "ropes" for string concatenation

[Rasmus Lerdorf]

On 03/23/2015 11:14 PM, Xinchen Hui wrote:

>>> from user land.  this won't change anything..
>>
>> Nothing to do with userland or not but code stabilization
> In that case, yeah. you might be right.
> 
> but from my opinion, simpler always means easier for maintaining
> 
> anyway, I hope this could be merged to 7.0(the second branch) :)

If you and Dmitry are comfortable with it for 7.0, go for it. This is
entirely internal and in your domain and it isn't something we could
have a sensible RFC about since there is no question it is a good
change. The only question is about implementation stability and frankly
we only have a handful of people able to make an intelligent call on
code at this level. If one of those people were to raise a flag, and so
far they haven't, then we might pause, otherwise full steam ahead.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Deprecate setlocale?

[Rasmus Lerdorf]

On 04/01/2015 09:15 AM, Dan Ackroyd wrote:
> Hi,
> 
> I'd like to get people's feedback for the idea of making setlocale be
> either deprecated and to be removed eventually or just increasing the
> warning level against people using it.
> 
> The short version of why we should do this is that setlocale breaks
> things. It is a process wide operation, that is not thread safe on
> most platforms. Although people use it to alter the way strings are
> output, it also breaks libraries that are assuming that they are
> running in a "C" locale.

The PHP setlocale() wrapper can be made threadsafe in a portable manner
via newlocale()/uselocale(), so that part isn't an issue. Someone just
needs to write the code for the threaded SAPIs. It hasn't been a high
priority due to how few people use non-Windows ZTS mode so far.

Obviously within the same process there may be issues with changing a
locale to something unexpected by subsequent code, but that is really a
bug in that code then. If some library function expects and only works
in the "C" locale, it should make sure it is in that locale before doing
anything and then restoring the locale back appropriately. And with a
bit of symbol trickery libraries that do actually call setlocale to
change it and restore it can be made to use our newlocale/uselocale
thread-local locale mechanism.

setlocale() is used quite a bit and for non-threaded, which is the bulk
of php usage, it tends to work quite well. It is annoying that it is
process-wide and as you noted that can cause issues, sure, and that the
current implementation isn't threadsafe, but it isn't something that is
technically unsolvable. Rather than throwing our hands in the air and
just pulling the rug out from under people using it, we should take a
look at fixing the problems associated with it instead.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Deprecate setlocale?

[Rasmus Lerdorf]

On 04/02/2015 02:13 PM, Dan Ackroyd wrote:
> Adam Harvey wrote:
>> What about just adding another function: setlocale_global(), or similar?
> 
> Do you mean setlocale would become the thread safe one, and
> setlocale_global() would be the current behaviour? If so, that would
> be a BC break for the small number of people who are deliberately
> using setlocale globally. We could do that at a major version I guess.
> 
> I think the ini setting is still better - it allows people to use code
> that was written assuming that setlocale was safe to use, rather than
> forcing them to change it.
> 
> It might be best to introduce both setlocale_ts() and
> setlocale_global(), so that users could call either explicitly, and
> have the ini setting control which one setlocale() points to. If we
> did that we could also then plan to eventually deprecate both the ini
> setting and the plain setlocale without _ts/_global.
> 
> Ryan Pallas wrote:
>> I like the idea of an INI actually, but I would make it default to the 
>> current behaviour and user education so those who need TS know to change it.
> 
> The problem with that is that for people who aren't aware of the
> setting, they wouldn't know that they need to change the setting.
> Instead they just want their code to work properly 'out of the box'.
> For the vast majority of people calling the thread safe version of
> setlocale would be what they problem want it to do, and so PHP should
> default to the right thing for the majority of people.
> 
> Of course there is a separate argument about changing the behaviour at
> major/minor version, and if this was introduced then having to
> `thread_safe_setlocale=off` for 7.1 and `thread_safe_setlocale=on` for
> 8 could be correct.

A step back here, please. Which concrete problem are you actually trying
to solve? HHVM needed this fix because of its single-process threaded
architecture on UNIX. PHP is not typically threaded on UNIX, so it
doesn't seem like an issue affecting very many people. It has been on
our radar for ages and has a big prominent red warning box about it in
the documentation. Threaded use of PHP on UNIX tends to be rather
specialized cases by people who understand that things like setlocale()
and putenv() are process-wide.

That doesn't mean there is anything wrong with implementing thread-local
setlocale for our threadsafe builds, and we should definitely fix any
in-process setlocale interference issues, but the thread safety part of
it just doesn't seem like something very many people are going to care
about. Why do you?

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Maintaining PHP LDAP module

[Rasmus Lerdorf]

On 05/05/2015 05:50 AM, Côme BERNIGAUD wrote:
> On 2015-05-05 14:26, Christoph Becker wrote:
>> It might be useful to state some references, such as already submitted
>> patches or pull requests, for instance.
> I posted a patch here: https://bugs.php.net/bug.php?id=69471
> 
> I did not send anything else yet because I wanted to see if I had any
> reaction first, and I got no answer to bugs I opened regarding php-ldap.
> I later saw that there are PR and patches fixing problems I have with no
> answer:
> https://bugs.php.net/bug.php?id=61853
> https://github.com/php/php-src/pull/652
> 
> That’s when I thought the php-ldap extension might need a new maintainer.

The ldap code could definitely use some attention. You have git access
now. Could you also go through the bug db and see if you can address
some of the longstanding reported issues?

-Rasmus




signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Re: [PHP-CVS] com php-src: Add targets to simplify building PHP with FDO (Feedback Directed Optimisation) PHP should be built with the folowing steps:: Makefile.global configure.in

[Rasmus Lerdorf]

On 05/26/2015 07:33 AM, Dmitry Stogov wrote:
> Commit:7dac4d449f72d7eb029aa1a8ee87aaf38e17e1c5
> Author:Dmitry Stogov  Tue, 26 May 2015 17:33:25 
> +0300
> Parents:   ca31711625095c2d6e308d7f0fc9d371ad0934d4
> Branches:  master
> 
> Link:   
> http://git.php.net/?p=php-src.git;a=commitdiff;h=7dac4d449f72d7eb029aa1a8ee87aaf38e17e1c5
> 
> Log:
> Add targets to simplify building PHP with FDO (Feedback Directed Optimisation)
> PHP should be built with the folowing steps:
> 
> make clean
> make -j4 prof-gen
> ; now php should be trained with some scripts
> ; for example `sapi/cgi/php -T 1000 /var/www/http/wordpress/index.php > 
> /dev/null`
> make prof-clean
> make -j4 prof-use
> 
> The "properly" trained build may give up to 10% real performance boost!
> "Improprly" trained PHP might be even slower.

Whoa, really 10%? I know there is AutoFDO coming in gcc 5.1 and I didn't
think this was really practical until then. Perhaps it is. I wonder if
this will spur php-wordpress, php-drupal and php-mediawiki tuned builds?

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Request for php-src karma

[Rasmus Lerdorf]

On 06/10/2015 03:25 PM, Christoph Becker wrote:
> Hi!
> 
> I'm requesting php-src karma (cmb@), mainly for bug-fix purposes.  I
> have already submitted several PRs[1], and several of them have already
> been merged.
> 
> It seems to me that it might save time, if I can commit obvious and
> uncontroversial fixes directly instead of making PRs first.

Done and thanks for all your help and patience on bugs.php.net.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP 7.0.0alpha1 Released for Testing!

[Rasmus Lerdorf]

On 06/12/2015 01:08 PM, Anatol Belski wrote:
> Hi Jordi,
> 
>> -Original Message-
>> From: Jordi Boggiano [mailto:j.boggi...@seld.be]
>> Sent: Friday, June 12, 2015 3:03 PM
>> To: internals@lists.php.net
>> Subject: Re: [PHP-DEV] PHP 7.0.0alpha1 Released for Testing!
>>
>> On 12/06/2015 01:53, a...@php.net wrote:
>>> The first alpha for 7.0.0 was just released and can be downloaded from:
>>>
>>> https://downloads.php.net/~ab/
>>>
>>> The Windows binaries are available at
>>>
>>> http://windows.php.net/qa/
>>
>> Yay!
>>
>> Thanks to everyone involved.
>>
>> Composer test suite passing and in -50% runtime than 5.6 which I can't
> complain
>> about :)
>>
> Thanks for the feedback. It's a good and an important sign :)

You can get even more speed by compiling with --enable-opcache-file and
then in your php-cli.ini add:

opcache.enable_cli=1
opcache.file_cache=/var/tmp
opcache.file_cache_only=1

Then every time you run composer it won't have to recompile everything.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP 7.0.0alpha1 Released for Testing!

[Rasmus Lerdorf]

> On Jun 13, 2015, at 14:54, Jan Ehrhardt  wrote:
> 
> Rasmus Lerdorf in php.internals (Fri, 12 Jun 2015 13:13:16 -0700):
>> You can get even more speed by compiling with --enable-opcache-file and
>> then in your php-cli.ini add:
>> 
>>   opcache.enable_cli=1
>>   opcache.file_cache=/var/tmp
>>   opcache.file_cache_only=1
>> 
>> Then every time you run composer it won't have to recompile everything.
> 
> I saw something referring to this in the commits. But some documentation
> would be welcome. I could not find any at the obvious places:
> http://php.net/manual/en/opcache.configuration.php
> https://github.com/zendtech/ZendOptimizerPlus
> 
> Is this documented elsewhere?

No, not yet. It is rather new and untested. And not enabled by default. There 
are still a few minor issues with it, but we need a few more people playing 
with it so we can work through those which is why I am suggesting folks here 
give it a try before we document and push it more broadly.

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] PHP-FPM: How to clear the realpath cache on deployment?

[Rasmus Lerdorf]

On 06/19/2015 08:43 AM, Sebastian Bergmann wrote:
>  Scenario: nginx + PHP-FPM / FastCGI.
> 
>  The final step of the deployment is updating a symlink to point to the
>  new version.
> 
>  For N <= realpath_cache_ttl seconds after the deployment, some
>  filesystem operations fail because of outdated realpath cache entries.
> 
>  Is there a way to signal the PHP-FPM / FastCGI processes to clear
>  the realpath cache? If not, I think this should be added :-)

I think this is a symptom of doing deploys incorrectly. If you are
flipping a symlink on a live server which can happen in the middle of a
request then your deploy mechanism is broken.

The web server should set the document_root to the target of the symlink
at the start of a request.

For nginx this is a built-in feature:

fastcgi_param DOCUMENT_ROOT $realpath_root;

For Apache I wrote a module to do it: https://github.com/etsy/mod_realdoc

Then there is never a question of needing to clear any caches at the PHP
level.

See: https://codeascraft.com/2013/07/01/atomic-deploys-at-etsy/
for a more indepth explanation.

-Rasmus



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] hasType() for internal function parameters?

[Rasmus Lerdorf]

Is it deliberate that we are not providing the parameter types for
internal functions via reflection? It seems inconsistent:

getParameters()[0];
$param_strlen = (new ReflectionFunction('strlen'))->getParameters()[0];

echo "$param_ustrlen (".$param_ustrlen->hasType().")\n";
echo "$param_strlen (".$param_strlen->hasType().")\n";

try {
ustrlen(1);
} catch (TypeError $e) {
echo $e->getMessage()."\n";
}

try {
strlen(1);
} catch (TypeError $e) {
echo $e->getMessage()."\n";
}

The output is:

Parameter #0 [  string $str ] (1)
Parameter #0 [  $str ] ()
Argument 1 passed to ustrlen() must be of the type string, integer
given, called in /home/rasmus/prop.php on line 11
strlen() expects parameter 1 to be string, integer given

That is, in both cases a TypeError exception is raised because the type
of the parameter is incorrect. But hasType() on the internal function
parameter claims there is no type even though there obviously is one.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

[Rasmus Lerdorf]

On 06/21/2015 02:44 PM, Nikita Popov wrote:
> The difference here is that ustrlen() has an argument type specified in
> arginfo, while strlen() triggers an error through
> zend_parse_parameters(). We have practically no arginfo-level type
> annotations in the standard library.

Obviously we can't look into a function to check what it is passing to
ZPP, but maybe ZPP could be made smarter and have it fill in the arginfo
if it isn't there. That sounds slow though.

Or we bite the bullet and fix the arginfo everywhere to make it
consistent. It wouldn't be that hard to write a script to generate the
bulk of it.

I just don't like the fact that a parameter can raise a type error when
it claims to not have a type. It makes writing static analysis and other
type checking tools much more complicated.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

[Rasmus Lerdorf]

On 06/21/2015 03:40 PM, Kalle Sommer Nielsen wrote:
> Hi
> 
> 2015-06-21 20:58 GMT+02:00 Rasmus Lerdorf :
>> Or we bite the bullet and fix the arginfo everywhere to make it
>> consistent. It wouldn't be that hard to write a script to generate the
>> bulk of it.
> 
> I think fixing arginfo sounds like the right solution, writing a
> script for it should not be so trival.

Even the ones that have some arginfo aren't all correct.

For example:

https://github.com/php/php-src/blob/master/Zend/zend_builtin_functions.c#L132

which currently says:

ZEND_BEGIN_ARG_INFO_EX(arginfo_define, 0, 0, 3)
ZEND_ARG_INFO(0, constant_name)
ZEND_ARG_INFO(0, value)
ZEND_ARG_INFO(0, case_insensitive)
ZEND_END_ARG_INFO()

That says there are 3 required params when it should clearly be 2.

But really that block should be:

ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_define, 0, 2, _IS_BOOL,
0, 0)
ZEND_ARG_TYPE_INFO(0, constant_name, IS_STRING, 0)
ZEND_ARG_INFO(0, value)
ZEND_ARG_TYPE_INFO(0, case_insensitive, _IS_BOOL, 0)
ZEND_END_ARG_INFO()

It seems way too lazy to not fix these before we release 7.0. Especially
the ones that are outright wrong. So, having called us lazy, I better
dig in and do something about it. I'll fix up all of the ones in
zend_builtin_functions.c today. And move on to others after. Definitely
a tedious task that we could use some extra hands on.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

[Rasmus Lerdorf]

On 06/21/2015 06:11 PM, Stanislav Malyshev wrote:
> Hi!
> 
>> Before making more extensive use of arginfo types, I think we should first
>> do some adjustments to the way they are handled. In particular adding types
>> means that internal fcalls will take the branch in
>> http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_vm_def.h#3669. As this is hot
>> code, it is likely important to avoid doing those duplicate type checks
>> (that will also happen in zpp anyway). As such I would suggest to make
>> arginfo for internal functions reflection-only. Return type hints are
>> already only enforced in debug mode.
> 
> Agreed, for internals arginfo types should be reflection-only. I imagine
> that would be very easy to fix just by checking for function type?

Ok, I have fixed the arginfo for all the built-in engine functions.
I wrote a little script which generates it from the doc-comments in the
code. I think the easiest way to do it is to first go through the file
and check the "{{{ proto" comments to make sure the optional args are
denoted correctly and no args are missing.

To run it:

script/dev/genarginfo.php Zend/zend_builtin_functions.c

for example.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

[Rasmus Lerdorf]

On 06/22/2015 05:11 AM, Dmitry Stogov wrote:
> Hi Rasmus,
> 
> Your latest changes broke more than 100 tests.
> Sorry, but I had to revert your commits and related Bob's fixes.
> You may find them in internal-arg-info branch.
> 
> Please, don't do experiments on the common code base at beta stage.
> On the other hand, I don't see a big problem committing this, when a
> complete solution is ready.

Oops, way more test failures than I expected. But I don't understand
some of them. For example, Zend/tests/constants_008.phpt which is:



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

[Rasmus Lerdorf]

On 06/22/2015 01:27 PM, Dmitry Stogov wrote:
> Actually, when you added type hints, php compiler stopped optimizing and
> using ZEND_DEFINED (and others) instead of internal function calls, but
> of course this shouldn't change behavior. I'll need to take a look into
> difference.

Right, behaviour shouldn't change, but couldn't we also make it so that
arginfo for internal calls is only used by reflection? We can do all the
type checking we need right in ZPP as we do now. Let's just ignore
arginfo entirely for these calls.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

[Rasmus Lerdorf]

On 06/22/2015 03:00 PM, Dmitry Stogov wrote:
> 
> 
> On Mon, Jun 22, 2015 at 8:35 PM, Rasmus Lerdorf  <mailto:ras...@lerdorf.com>> wrote:
> 
> On 06/22/2015 01:27 PM, Dmitry Stogov wrote:
> > Actually, when you added type hints, php compiler stopped optimizing and
> > using ZEND_DEFINED (and others) instead of internal function calls, but
> > of course this shouldn't change behavior. I'll need to take a look into
> > difference.
> 
> Right, behaviour shouldn't change, but couldn't we also make it so that
> arginfo for internal calls is only used by reflection? We can do all the
> type checking we need right in ZPP as we do now. Let's just ignore
> arginfo entirely for these calls.
> 
> 
> In general, we can, if we remove corresponding code in zend_vm_def.h,
> and also some checks for ZEND_HAS_TYPE_INFO and internal functions in
> zend_compile.c.

I think that is the way to go. We didn't have any type info there before
so we are not losing any functionality, and obviously adding it produces
weird side effects and slows things down. Plus we should get a very
small performance increase by removing the type info check entirely.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

[Rasmus Lerdorf]

On 06/22/2015 07:54 PM, Stanislav Malyshev wrote:
> Hi!
> 
> So I tried to remove the checks for ZEND_ACC_HAS_TYPE_HINTS:
> https://github.com/php/php-src/pull/1354
> 
> Turns out there is a lot of tests that assume function with wrong
> arguments throws Error, but ZPP and type checks work differently - ZPP
> first checks argument number (and doesn't throw if number is wrong but
> instead creates warning), while type checks (that shouldn't really
> happen on internals but do) check types first and not check argument number.
> 
> So I wonder which way is the best to proceed here. Looks like this comes
> from 5.6 where internal function types were verified in executor:
> https://github.com/php/php-src/blob/PHP-5.6/Zend/zend_vm_def.h#L1974
> 
> I'm not sure what to do with it - on one side, I think ZPP should handle
> it for internal functions, otherwise we're doing the same work twice. On
> the other side, that would be pretty substantial, even if maybe correct,
> BC break. Should we keep the ZEND_ACC_HAS_TYPE_HINTS type checks and
> accept the fact that this way we're checking everything twice, or should
> be clean it up?

Is it a BC break against real code though? Fixing tests isn't a big
deal. What kind of real code would break by turning calls with the wrong
number of args from an error to a warning?

I suppose it is a bit late in the game to fix this, but it really does
seem very broken to the point where I wonder if we shouldn't just
disable reflection on internal functions entirely since the arginfo is
so woefully incomplete. Plus the double-checking is super messy.

-Rasmus





signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

[Rasmus Lerdorf]

On 06/22/2015 11:51 PM, Stanislav Malyshev wrote:
> Hi!
> 
>> Is it a BC break against real code though? Fixing tests isn't a
>> big deal. What kind of real code would break by turning calls with
>> the wrong number of args from an error to a warning?
> 
> Well, if we move to checking in ZPP only, then some of the errors that
> previously were fatals (like iterator_array("")) would now become
> warnings. In fact, even type mismatch is a warning for ZPP, which may
> be unexpected, as it was a fatal before, so we may want to change that.
> 
> But in some situation, like argument number mismatch, we will have a
> warning, where before it was a fatal error. Which isn't strictly BC
> break but allows some code to pass which previously didn't and may
> hide some bugs.
> 
> So we may want to be careful there.

I suppose so, but this seems like a relatively minor level of BC
breakage especially for a major version bump.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] New PHP SAPI for Nginx

[Rasmus Lerdorf]

On 06/25/2015 01:31 PM, S.A.N wrote:
> New versions Nginx, implement thread pools,
> http://nginx.com/blog/thread-pools-boost-performance-9x/
> 
> I think this is a good opportunity to write a Nginx module (PHP SAPI)
> which is to process requests for PHP scripts in processes Nginx.
> 
> Quality advantages, as compared with the FPM, no network overhead,
> less memory consumption, may be implemented mode ZTS (Zend Thread
> Safety).

Putting an entire PHP request in one of these nginx threads seems like a
bad idea to me. Tons of things in PHP or in libraries called by PHP are
blocking, plus ZTS mode is slower, uses more memory than non-ZTS mode
and is in general just more complex to work with, especially when it
comes to process-wide things like env, locale and signals. Having a
clear separation between PHP and the web server makes many things much
simpler and more robust. You can also already do nginx to php-fpm
without any network overhead by using a unix domain socket.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP7 and types

[Rasmus Lerdorf]

On 07/12/2015 12:37 PM, Larry Garfield wrote:
> I don't know why we're even talking about IDEs here.  IDE
> auto-completion isn't the point, anymore than it was the point for
> scalar type hints or return type hints.  It's about the language doing
> type checking for you and static analysis, so that the language can find
> bugs for you. Eg:
> 
> class Foo {
>   public Bar $bar;
> }
> 
> $f = new Foo();
> $f->bar = new Baz(); // This line is clearly wrong and the compiler can
> check it for you.
> 
> That's what the benefit would be.  Easier IDE auto-completion is a nice
> extra, but not the main goal.
> 
> +1 from me in 7.1.

I am not sure static analysis is a great argument for it either. A
static analyzer can read the docblock really easily too since it is part
of the AST node for the property. In fact I just wrote one. Feeding it
your code example:

% cat -n test.php
 1  bar = new Baz();

% ./phan test.php
Files scanned: 1
Time:   0.11s
Classes:2
Methods:0
Functions:  0
Closures:   0
Traits: 0
Conditionals:   0
Issues found:   1

test.php:9 TypeError property is declared to be bar but was assigned Baz

Plus, without union types, doc-comment typing is much more convenient
when it comes to running a static analyzer on real-world code since
limiting everything to a single type is often impractical. If you grep
through existing code in the wirld, you will find a ton of Bar|bool,
Bar|Baz|bool|null, etc.

I'm not against the idea, but it is quite different from the existing
type checking since this is a type check that would need to be done on
every assignment for it to make any sense at all and not just at call
boundaries like the existing ones. It may not be feasible to do in an
efficient manner. A static analyzer can get away with catching 95%. A
core language feature can't. Having to do these the type check on
assignment will likely require some significant changes to the engine.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP7 and types

[Rasmus Lerdorf]

On 07/12/2015 05:12 PM, Rasmus Lerdorf wrote:
> On 07/12/2015 12:37 PM, Larry Garfield wrote:
>> I don't know why we're even talking about IDEs here.  IDE
>> auto-completion isn't the point, anymore than it was the point for
>> scalar type hints or return type hints.  It's about the language doing
>> type checking for you and static analysis, so that the language can find
>> bugs for you. Eg:
>>
>> class Foo {
>>   public Bar $bar;
>> }
>>
>> $f = new Foo();
>> $f->bar = new Baz(); // This line is clearly wrong and the compiler can 
>> check it for you

By the way, I forgot to add that you can't possibly say that this line
is clearly wrong without knowing what Baz is and you didn't define Baz.
So the only thing clearly wrong with that line is that the Baz class
doesn't exist which has nothing to do with the property type.

If you have:

class Bar { }
class Baz extends Bar { }

Then that line is perfectly valid since Baz is an instance of Bar which
would meet the type criteria provided. And this also shows that the
compiler can't actually check that necessarily. We don't know whether
Baz is an instance of Bar at compile-time.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: AW: [PHP-DEV] PHP7 and types

[Rasmus Lerdorf]

On 07/13/2015 12:16 AM, Robert Stoll wrote:
> Another point of discussion should be how strict a property type hint will 
> be. Currently, parameter type hints are only binding for the call side but 
> not within the function body.
> For instance, function foo(Foo $x){ $x = 1;} is perfectly valid. It certainly 
> has little sense to have the same semantics for properties but then we 
> introduce another inconsistency and should maybe fix the behaviour of 
> parameter type hints first.

Like I said, adding type checks to every assignment is a rather large
change, and I doubt it can be done without some nasty performance costs.

Honestly, I would rather have a speedy runtime and put the effort into a
static analysis mode built into PHP. The stated goal of so many who push
the strict types everywhere argument is that it helps find bugs. So
let's have an analyze mode that finds these bugs without bogging down
the runtime with thousands of type checks.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Introductions

[Rasmus Lerdorf]

On 07/13/2015 11:23 AM, Matt Tait wrote:
> Hi all,
> 
> I'm Matt Tait; a security researcher at Google, and I'm quite interested in
> looking at and helping to build new security-related features within PHP;
> i.e. features that reduce the likelihood that deployments of PHP end up
> being hacked.
> 
> In the short term, I'm quite interested in looking at ensuring that all of
> the compiler and operating-system security features are enabled by default,
> and later I hope to be looking at both hardening the PHP core against
> various categories of memory-corruption vulnerability. Hopefully this work
> will also end up improving the performance and security of various parts of
> PHP core.
> 
> In the longer-term I'm also interested in building user-visible features
> for PHP that would allow developers who want or need to deploy PHP to
> sensitive environments to prevent certain categories of error across their
> entire codebase (such as SQL injection and so on) that are commonly used by
> hackers. This would be particularly useful for many less-technical
> companies who are worried about hackers, but unable to ensure that every
> component they plug in to their website is coded with security-in-mind.
> 
> I look forward to working with you all to make PHP a better product for PHP
> developers and website owners!

Sounds great.

There is some intro info along with the git account request form here:
http://php.net/git-php.php

-Rasmus






signature.asc
Description: OpenPGP digital signature

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

[Rasmus Lerdorf]

On 08/21/2015 06:36 AM, Anthony Ferrara wrote:
> My proposal/stance:
> 
> Let's make random_* throw an Exception if it cannot connect to a
> random source. And let's have it throw an TypeError if ZPP fails, or
> Error if min >= max.
> 
> The first two are consistent with existing exceptions.

I don't think anyone would argue those two. It makes sense.

> The third (Error if min>max) is where the contention lies. I'm
> suggesting Error as it's consistent with parameter errors in the sense
> that the type may be correct, but the value isn't (hence it's the same
> kind of error as a parameter error, just a different
> sub-classification.
> 
> MHO is this is too important of a distinction to simply gloss over.
> Having it return false (or null) will be a problem, as nobody will
> perform the error checks. And returning $x where `$x == 0` in a
> security context could be incredibly bad. As such, I think the
> security implications here outweigh nearly all of the other concerns
> about consistency and convention.
> 
> That's my opinion. I'll be happy to make the changes if a RM gives me
> the green light to do so.

An error on this makes sense to me too and it doesn't seem like much of
an issue to make this change now. But yes, it is the RM's final call.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Phalanger

[Rasmus Lerdorf]

On 12/08/2011 03:28 PM, Rasmus Schultz wrote:
> Don't take this the wrong way, I'm merely trying to provoke your thoughts a
> bit with this e-mail! :-)
> 
> Has it occurred to anyone, to abandon the official PHP codebase and adopt
> Phalanger instead?
> 
> Some convincing (to me) points:
> 
> - Phalanger runs on Mono, meaning similar platform-reach as PHP. (but
> eliminating most platform-specific implementations.)
> 
> - It's fast. (probably fast enough to mostly eliminate the need for native
> extensions in general.)
> 
> - The community would be able to write modules/extensions in PHP or other
> CLR languages.
> 
> - It's secure. (not that C/FFI PHP extensions tend not to be trustworthy,
> but they do tend to come from a relatively small group of authors.)
> 
> - Access to more languages means a much bigger community who can contribute
> extensions and core patches.
> 
> - Access to existing CLR codebases means more third-party libraries can be
> readily integrated without writing and maintainting C/FFI wrappers.
> 
> - The codebase is new, clean and modern (it's not dragging around a lot of
> legacy baggage.)
> 
> - Fully take advantage of new 64-bit hardware (vector computations and
> larger address space) in all aspects. (core, extensions, PHP scripts).
> 
> I'm not going to try to sell you on the fact that the integration with the
> Windows world is tighter in Phalanger than in PHP - but it is a point that
> carries considerable weight  to many businesses.
> 
> People I know have had a tendency to view Phalanger as "PHP for Windows" -
> it's really not. It's PHP for CLR - and CLR is not (only) Windows. And it
> is readily available on most modern operating systems with good support for
> various hardware platforms.
> 
> Now, before you start flaming me - I'd love to hear precisely why you're
> eager to hang on to the C codebase. What are the benefits of the C codebase
> over Phalanger?
> 
> I understand the licensing may be an issue. It may be the argument that
> outweighs everything else, but I'm curious to hear what else would keep you
> from moving to Phalanger?

This is a complete non-starter. The bulk of PHP users are on
non-Windows, especially Linux, and Mono performance on Linux is really
not good. Last time I checked it was an order of magnitude slower on
Linux compared to the same hardware running Windows. Granted that was
quite a few years ago now and I assume it is no longer 10x slower.
Perhaps it is up to 4x or even 2x slower.

-Rasmus

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

Re: [PHP-DEV] Phalanger

[Rasmus Lerdorf]

On 12/08/2011 03:53 PM, Rasmus Lerdorf wrote:
> This is a complete non-starter. The bulk of PHP users are on
> non-Windows, especially Linux, and Mono performance on Linux is really
> not good. Last time I checked it was an order of magnitude slower on
> Linux compared to the same hardware running Windows. Granted that was
> quite a few years ago now and I assume it is no longer 10x slower.
> Perhaps it is up to 4x or even 2x slower.

Here are some more recent numbers to back that up:

http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx

Basically what you are suggesting is that we replace the Green bar there
with the Grey one. Note that lower is better. This does show that Mono
performance is starting to approach .Net performance, at least for this
benchmark, but it still isn't there. And if you look through the various
benchmarks you will see that native C/C++ code is 5-10x faster than the
same code running under Mono.

-Rasmus


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

Re: [PHP-DEV] Is Bug #34972 (no non-blocking on STDIN on Windows) going to be fixed?

[Rasmus Lerdorf]

It is non-trivial to implement on Windows. It is more of a feature request than 
a bug. UNIX supports non-blocking stdin natively, Windows doesn't. A Windows 
guy would need to write a compatibility layer to get this to work and we don't 
have very many Windows guys around.

-Rasmus

On Dec 8, 2011, at 4:34 PM, Jonathan Chan  wrote:

> Hello,
> 
> Is there any intention to fix Bug #34972
> (https://bugs.php.net/bug.php?id=34972)? It was first submitted six
> years ago, but the bug still seems to exist.
> 
> Thanks.
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[Rasmus Lerdorf]

On 12/22/2011 07:08 AM, Keloran wrote:
> i would love to see this expanded aswell (the way type hinting on function
> variables was supposed to be), so that it could be
> 
> string, int
> 
> e.g.
> function int test(bool $tester) {
>  if ($tester) { return 5; }
>  return 99;
> }

Return type hinting needs to be aligned with parameter type hinting, and
as has been pointed out many times on this list, type hinting for
interchangable scalar types is a really bad idea. It will push all type
checking up to the caller of the underlying functions/methods. PHP is
primarily a Web scripting language and the Web isn't typed. Having stuff
like this break:

if(age_check($_POST['age'])) { do_stuff(); }

because the author of the age_check() function added an int type hint
just doesn't make any sense. It would cause everyone to have to start
casting things everywhere, just in case. eg.

if(age_check((int)$_POST['age'])) { do_stuff(); }

This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.

-Rasmus

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

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[Rasmus Lerdorf]

On 12/22/2011 10:51 AM, Sebastian Bergmann wrote:
> Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
>> This is not a step forward. If the author of age_check() really doesn't
>> want to accept type-juggled arguments, then it is easy enough to do a
>> strict type check in the function itself. This puts the effort in the
>> correct place and doesn't encourage this type of coding.
> 
>  Putting such code into the "correct" place does not change the problem
>  that you and Stas describe
> 
>  function age_check($age)
>  {
>  if (!is_int($age)) {
>  throw new InvalidArgumentException;
>  }
>  }
> 
>  With the above code, the caller needs to cast and the writer of the
>  age_check() function has to copy/paste/adapt these checks to all the
>  correct places ...
> 
>  I am not advocating type hints for scalars, I am just saying that this
>  argument is not really a good one against it.

But people don't really write code like this in PHP. Which is also why
it makes very little sense to add strong typing of scalars. Why would
anyone want to add a feature that lets them do something they would
never do?

The above code is much more likely to do an is_numeric() check and/or a
hard typecast to an int. But throwing an exception when it receives "21"
instead of 21 just isn't something people tend to do.

And Dmitri, in the Mongo case you mentioned, parameters to Mongo need to
be json-wrapped, so you are going to have access functions doing this.
Why would you not want to typecast in the access function there as well
as opposed to throwing hard to catch exceptions going into the access
functions themselves?

The only way I see something like this ever happening in PHP is if we
came up with an intelligent approach that actually was type *hinting*
and not strong typing. As in:

function ((int)$age) {
  return ($age > 21) ?: false;
}

that would gracefully handle interchangeable types. But it gets tricky
once we start thinking about non-numeric strings being passed in there.

-Rasmus

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

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[Rasmus Lerdorf]

On 12/22/2011 11:18 AM, Will Fitch wrote:
> On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote:
> 
>> On 12/22/2011 07:08 AM, Keloran wrote:
>>> i would love to see this expanded aswell (the way type hinting on function
>>> variables was supposed to be), so that it could be
>>>
>>> string, int
>>>
>>> e.g.
>>> function int test(bool $tester) {
>>> if ($tester) { return 5; }
>>> return 99;
>>> }
>>
>> Return type hinting needs to be aligned with parameter type hinting, and
>> as has been pointed out many times on this list, type hinting for
>> interchangable scalar types is a really bad idea. It will push all type
>> checking up to the caller of the underlying functions/methods. PHP is
>> primarily a Web scripting language and the Web isn't typed. Having stuff
>> like this break:
> 
> Have you taken a look at the RFC and/or patch?  This functionality is exactly 
> aligned with parameter type hinting.  Only classes, arrays and callables are 
> allowed types.   I agree 100% on scalars.

Yes, I know, but any talk about typing invariable brings the strong
typing scalars proponents out of the woodwork.

-Rasmus

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

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[Rasmus Lerdorf]

On 12/22/2011 11:20 AM, Dmitri Snytkine wrote:
> Not sure what you mean by json wrapped.
> In mongo you do $coll->find(array('age' => $age);
> 
> if $age is a string '21' your will not get any erros but neither will you
> get any results.

It is json underneath, but in your find() example, obviously the right
approach here is to do:

  $coll->find(array('age' => (int)$age);

How is that hard?

You wouldn't use a strong int type in the find() function prototype here
at all since by definition the find() function needs to take all sorts
of types. This is why I mentioned access functions related to Mongo. You
might write something like:

  function age_lookup($age) {
return $coll->find(array('age' => (int)$age);
  }

but again here, doing a strong type check on the parameter isn't making
your life easier. It simply pushes the responsibility to the caller and
introduces a tricky unrecoverable error that will drive you crazy unless
you have 100% regression test coverage (which is kind of impossible
since the number of inputs is infinite) or great static analysis tools.
PHP is not a compiled language, so you end up not catching these until
runtime which is obviously sub-optimal.

-Rasmus

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

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[Rasmus Lerdorf]

On 12/22/2011 11:49 AM, John Crenshaw wrote:
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] 
> 
>> How is that hard?
>>
>>   function age_lookup($age) {
>> return $coll->find(array('age' => (int)$age);
>>   }
>>
>> but again here, doing a strong type check on the parameter isn't making your 
>> life easier. It simply pushes the responsibility to the caller and 
>> introduces a tricky unrecoverable error that will drive you crazy unless you 
>> have 100% regression test coverage (which is kind of impossible since the 
>> number of inputs is infinite) or great static analysis tools.
> PHP is not a compiled language, so you end up not catching these until 
> runtime which is obviously sub-optimal.
> 
>> -Rasmus
> 
> This will silently fail in a very bad way when the caller accidentally passes 
> in (for example) an array. With a scalar type hint it would die loudly 
> (quickly alerting the developer to the problem) and code analysis tools (even 
> just a decent IDE) could highlight the error even before it is executed.

That's an argument for "scalar" as the type hint, not for "int" vs.
"string". I'm not against "scalar" as a type hint. I am against hints
that prevent interchangeable types from being passed. scalar, array,
object, callable are fine.

-Rasmus

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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 11:46 AM, Ferenc Kovacs wrote:
> On Wed, Jan 4, 2012 at 8:37 PM, Stas Malyshev wrote:
> 
>> Hi!
>>
>>
>> Could you please elaborate on that part - where is the disclosure
>>>and what exactly is being disclosed?
>>>
>>>
>>> I would guess that the value of that said limit. (it is the only
>>> variable in the error message).
>>>
>>
>> This is an error message, it's not visible to anybody. Even if it were, I
>> don't see a problem with it. Usually people mean different thing by
>> information disclosure, but without proper report of course it is
>> meaningless to talk about it.
> 
> 
> /* do not output the error message to the screen,
> this helps us to to avoid "information disclosure" */
> 
> I don't think that it is a high importance, but with display_errors
> enabled, it does leak otherwise unobtainable (if you don't have publicly
> available phpinfo files, which most person with enabled display_errors
> does) info.
> 
> So while I don't feel strongly about it, I wanted to mention it.

Since it is one of these remotely-triggered errors that you can't
program around, it should probably be suppressed when display_errors is
on. There is another precedence for this, but I am drawing a blank on
where else we did this right now.

-Rasmus


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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 11:54 AM, Nikita Popov wrote:
> On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf  wrote:
>> Since it is one of these remotely-triggered errors that you can't
>> program around, it should probably be suppressed when display_errors is
>> on. There is another precedence for this, but I am drawing a blank on
>> where else we did this right now.
>>
>> -Rasmus
> You mean like with htmlspecialchars() before PHP 5.4? Please don't.
> It's really non-obvious to start hiding errors as soon as you enable
> error display.

But there is a very valid security concern here. People can usually run
safely with display_errors enabled if their code is well-written. They
can check for potential errors and avoid them. This one can't be checked
for and you could easily write a scanner that scoured the Net for sites
with display_errors enabled by sending a relatively short POST request
to each one and checking for this error. And there is absolutely nothing
people could do about this short of turning off display_errors which we
know from experience a lot of people just don't do no matter how much we
suggest it.

The alternative is to just not have any error message at all. That
avoids the discrepancy between the error messages with display_errors on
and off.

-Rasmus

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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 12:19 PM, Reindl Harald wrote:
> 
> 
> Am 04.01.2012 21:07, schrieb Paul Dragoonis:
> 
>> I agree with Rasmus here. A lot of people keep display_errors
>> on, even when they shouldn't.
> 
> it is not the job of a programming language stop admins from
> beeing stupid - the defaults have to be sane and this is
> display_error OFF, if somebody decides for whateever reason to turn
> it on it is not yours or anybody others decision to ignore the
> setting here, and there and there also but there not

Yes, but display_errors is not off by default, that is the problem. If
we could get away with turning display_errors off by default, then I
agree that we don't need this. As it is currently, the default setup,
if people don't do anything, will result in a security problem because
of this.

-Rasmus

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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 12:46 PM, Johannes Schlüter wrote:
> On Wed, 2012-01-04 at 12:29 -0800, Stas Malyshev wrote:
>> Hi!
>>
>>> But there is a very valid security concern here. People can usually run
>>> safely with display_errors enabled if their code is well-written. They
>>
>> Oh no. Nobody should or can safely run production with display_errors. 
>> Everybody thinks their code is well-written, but display_errors should 
>> never be enabled in production, however high is your opinion of the code.
>> I'm afraid people now will start quoting this saying "ok, yeah, if 
>> you're a bad programmer, disable display_errors, but I'm a good 
>> programmer, my code is solid, I even have a dozen of unit tests, so I 
>> just go ahead and enable display_errors" and then we have this sad state 
>> of affairs where sites spill out error messages that are never supposed 
>> to be seen by clients because developers thought it can never happen.
> 
> On shared hosts display_errors typically is on, but the application can
> do ini_set('display_errors', 0) or such ...

But that is precisely why this is a special case. Even if you do
ini_set('display_errors', 0) in your code this message will still be
displayed. Although, display_startup_errors is off by default and
hopefully this one falls under that setting. I didn't test it, but if it
doesn't then we need to make sure it is suppressed when
display_startup_errors is off.

-Rasmus

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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 01:01 PM, Ferenc Kovacs wrote:
> I just got the tip that this error is only shown
> if display_startup_errors is set to true, and because it is in the
> startup routine the file path in the error message (which is the real
> infoleak) would only point to "unknown 0".
> If somebody has the time to double check/test this, it would be nice. 

Right, like I said in my previous message, if this is caught by
display_start_errors, I am ok with it. We need the default/no php.ini
file case to not leak information like this.

-Rasmus

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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 01:27 PM, Stas Malyshev wrote:
> Hi!
> 
>> Right, like I said in my previous message, if this is caught by
>> display_start_errors, I am ok with it. We need the default/no php.ini
>> file case to not leak information like this.
> 
> Just checked - it does not display error if display_startup_errors if
> off, does display if it's on.

Right, that seems ok. The other thing is that we need to clarify that it
actually only limits the number of variables per nesting level. The
current name and the description doesn't make that clear. You can still
send 1M post vars in a single POST if you just nest them in a 1000x1000
2d array. Of course, this is likely going to hit the post_max_size
limit, although many sites that do file uploads will have cranked that
way up.

-Rasmus

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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote:
> On 01/04/2012 01:27 PM, Stas Malyshev wrote:
>> Hi!
>>
>>> Right, like I said in my previous message, if this is caught by
>>> display_start_errors, I am ok with it. We need the default/no php.ini
>>> file case to not leak information like this.
>>
>> Just checked - it does not display error if display_startup_errors if
>> off, does display if it's on.
> 
> Right, that seems ok. The other thing is that we need to clarify that it
> actually only limits the number of variables per nesting level. The
> current name and the description doesn't make that clear. You can still
> send 1M post vars in a single POST if you just nest them in a 1000x1000
> 2d array. Of course, this is likely going to hit the post_max_size
> limit, although many sites that do file uploads will have cranked that
> way up.

Oh, and a final issue to address.

This code:

for($data=[],$i=0; $i<=999; $i++) $data[$i] = range(0,1001);
echo curl_post("http://localhost/index.php";,['a'=>$data]);

will spew the warning 2000 times.

& php post.php | grep Warning | wc -l
2000

-Rasmus

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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 08:13 PM, Laruence wrote:
> On Thu, Jan 5, 2012 at 5:56 AM, Rasmus Lerdorf  wrote:
>> On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote:
>>> On 01/04/2012 01:27 PM, Stas Malyshev wrote:
>>>> Hi!
>>>>
>>>>> Right, like I said in my previous message, if this is caught by
>>>>> display_start_errors, I am ok with it. We need the default/no php.ini
>>>>> file case to not leak information like this.
>>>>
>>>> Just checked - it does not display error if display_startup_errors if
>>>> off, does display if it's on.
>>>
>>> Right, that seems ok. The other thing is that we need to clarify that it
>>> actually only limits the number of variables per nesting level. The
>>> current name and the description doesn't make that clear. You can still
>>> send 1M post vars in a single POST if you just nest them in a 1000x1000
>>> 2d array. Of course, this is likely going to hit the post_max_size
>>> limit, although many sites that do file uploads will have cranked that
>>> way up.
>>
>> Oh, and a final issue to address.
>>
>> This code:
>>
>> for($data=[],$i=0; $i<=999; $i++) $data[$i] = range(0,1001);
>> echo curl_post("http://localhost/index.php";,['a'=>$data]);
>>
>> will spew the warning 2000 times.
>>
>> & php post.php | grep Warning | wc -l
>> 2000
>>
> could you try with this new patch:
> https://bugs.php.net/patch-display.php?bug_id=60655&patch=max_input_vars.patch&revision=latest
> ?
> 
> this patch also restrict the json / serializer ,  all of them must
> less than PG(max_input_vars).
> 
> and different with the fix which was commited now,  this patch count
> the num vars in a global scope, that means if there are 2 elements
> which both have 500 elements in post,  the restriction will also
> affect,
> 
> and this patch will not affect the existsing called to json or
> serializer,   only affect the zif_json_decode and zif_serialize,
> after patch, the serialize will have a sencode parameter :"$max_vars".
> 
> and the restriction can also be closed by set max_input_vars to 0.

Right, I don't think this is going to work. A simple 'make install'
after applying your patch fails with:

Warning: unserialize(): Unserialized variables exceeded 1000 in
phar:///home/rasmus/php-src/branches/PHP_5_4/pear/install-pear-nozlib.phar/PEAR/Registry.php
on line 1145

Warning: unserialize(): Unserialized variables exceeded 1000 in
phar:///home/rasmus/php-src/branches/PHP_5_4/pear/install-pear-nozlib.phar/PEAR/Registry.php
on line 1145

Warning: unserialize(): Unserialized variables exceeded 1000 in
phar:///home/rasmus/php-src/branches/PHP_5_4/pear/install-pear-nozlib.phar/PEAR/Registry.php
on line 1145
[PEAR] PEAR: pear.php.net/PEAR not installed

I really don't think this manual per-feature limiting is going to cut it
here. The real problem is the predictability of the hashing which we can
address by seeding it with a random value. That part is easy enough, the
hard part is figuring out where people may be storing these hashes
externally and providing some way of associating the seed with these
external caches so they will still work.

-Rasmus

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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 11:09 PM, Stas Malyshev wrote:
> Hi!
> 
>> I really don't think this manual per-feature limiting is going to cut it
>> here. The real problem is the predictability of the hashing which we can
>> address by seeding it with a random value. That part is easy enough, the
>> hard part is figuring out where people may be storing these hashes
>> externally and providing some way of associating the seed with these
>> external caches so they will still work.
> 
> I think we'd need and API to access the seed value and to calculate hash
> for given seed value. That would probably allow extensions that store
> hashes with some additional work to do it properly. Though it needs more
> detailed investigation.

Yes, but we still need an actual case to look at. Opcode caches
shouldn't be a problem unless they store some representation on disk
that live across server restarts. In the APC world, nobody does that. Is
there something in common use out there that actually needs this?

Let's do just the GPC fix (the Dmitry version) for 5.3 and turn on
ignore_repeated_errors just during startup and get it out there. That
takes care of the most obvious attack vector for existing users. Leaving
this in place for 5.4 is fine regardless of what we do in 5.4.

I think for 5.4 we should take a couple of days to dig into what would
actually break from seeding the hash. This seems like a much more
elegant solution compared to trying to add limits to all the other
places manually. This manual limit checking also wouldn't cover 3rd
party extensions or even userspace code that might be vulnerable to the
same thing. The only way to fix those cases is with a central hash fix.

Another alternative to seeding would be to use a different hashing
algorithm altogether. That would solve the cross-server issues, at the
likely cost of slower hashing.

-Rasmus

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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 11:33 PM, Stas Malyshev wrote:
> Hi!
> 
>> Yes, but we still need an actual case to look at. Opcode caches
>> shouldn't be a problem unless they store some representation on disk
>> that live across server restarts. In the APC world, nobody does that. Is
> 
> It's not that simple. Take example of FastCGI setup where processes can
> live and die independently (note that FastCGI does not mandate
> single-parent fork and in fact on Windows it doesn't work that way). In
> this setup opcode cache is shared between processes which may have
> different hash value, unless we give means to the cache to set this
> value on startup somehow.

hrm, ok, yes for non single parent forks it is an issue. For APC there
is no such thing, although people have been asking for it.

With a clean API this doesn't sound insurmountable though.

get_hash_seed()/set_hash_seed() internal functions. When the cache is
created the first time call get_hash_seed() and store it somewhere. When
someone connects to an existing cache the first time, fetch the stored
hash seed and call set_hash_seed()

-Rasmus

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

Re: [PHP-DEV] Re: another fix for max_input_vars.

[Rasmus Lerdorf]

On 01/04/2012 11:49 PM, Laruence wrote:
> Hi:
>   there is one way  maybe is a good try.
> 
>   when resize hashtable,  we don't just dobule the size,  instead, we
> increase the hashtable size with a random delta
> 
>  what do you think?

Sorry, you lost me. How does that help? The problem is when we collide
on a single hash key the resulting linked list traversion gets longer
and longer as more colliding keys are added to that hashtable. Whether
you double the size or grow it by some other factor doesn't change this.

-Rasmus


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

Re: [PHP-DEV] Re: 5.3.9, Hash DoS, release

[Rasmus Lerdorf]

On 01/09/2012 08:50 AM, Xinchen Hui wrote:
> Hi:
> I am not sure whether you have understood my point.
> 
> If an array have more than 1024 buckets in an same bucket
> list(same index), there must already be an performance issue.

The problem is you really need to consider the source. There are many
places where people deal with huge datasets. If they assign it directly
they shouldn't hit any limits or we would need some sort of "large
array" hint which would be nasty.

-Rasmus

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

Re: [PHP-DEV] Re: 5.3.9, Hash DoS, release

[Rasmus Lerdorf]

On 01/09/2012 09:18 AM, Xinchen Hui wrote:
> Sent from my iPhone
> 
> 在 2012-1-10，1:14，Rasmus Lerdorf  写道：
> 
>> On 01/09/2012 08:50 AM, Xinchen Hui wrote:
>>> Hi:
>>>I am not sure whether you have understood my point.
>>>
>>>If an array have more than 1024 buckets in an same bucket
>>> list(same index), there must already be an performance issue.
>>
>> The problem is you really need to consider the source. There are many
>> places where people deal with huge datasets. If they assign it directly
>> they shouldn't hit any limits or we would need some sort of "large
>> array" hint which would be nasty.
> Rasmus:
> 
> Large array ! = Large list
> 
> An array can have million elements withou exceed the limit ion of max
> length of list.

I understand the difference. But large arrays are obviously the ones
that are prone to hitting the collision limits.

-Rasmus

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

Re: [PHP-DEV] Re: 5.3.9, Hash DoS, release

[Rasmus Lerdorf]

On 01/09/2012 05:28 PM, Xinchen Hui wrote:
>> I understand the difference. But large arrays are obviously the ones
>> that are prone to hitting the collision limits.
> Yes, but don't you think this is at least better than restricting
> number of elements? :)

The difference is the source. If, for example, I have a huge array
cached in APC's user cache which I built up over time and I apc_fetch()
it directly, I would not expect to run into any such limits. However, if
I hit an external source and parse untrusted xml/json data then I would
appreciate being able to protect myself from this sort of attack.

-Rasmus

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

Re: [PHP-DEV] disabling ereg

[Rasmus Lerdorf]

On 01/10/2012 11:33 AM, Philip Olson wrote:
> Any objections? Regardless of deprecation status, this option
> should be available. Or if not, why?

The main reason is that we are not done removing all the dependencies.
This is a large deprecation that is going to require the process to span
multiple versions. We could add a way to disable it, but it is going to
break some extensions in ways that are not obvious to the user.

-Rasmus

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

Re: [PHP-DEV] FD_SETSIZE warning?

[Rasmus Lerdorf]

On 01/13/2012 05:13 AM, Hannes Landeholm wrote:
> I'm flooded with this warning when my system is under a high load and uses
> a lot of sockets/file descriptors. I get it in stream_select:
> 
> "E_WARNING: E_WARNING caught: stream_select(): You MUST recompile PHP with
> a larger value of FD_SETSIZE.
> It is set to 1024, but you have descriptors numbered at least as high as
> 1024.
>  --enable-fd-setsize=2048 is recommended, but you may want to set it
> to equal the maximum number of open files supported by your system,
> in order to avoid seeing this error again at a later date."
> 
> Why would you even have a limit for this? Having your application suddenly
> crash because of some undocumented arbitrary internal PHP limit is a real
> punch-in-the-face for people trying to build robust PHP-CGI applications.
> Can someone explain to me why I need to be bothered about this?

FD_SETSIZE is a system limit on the number of open files a single
process can have. From a bash shell type: ulimit -n
and you will probably see this magical 1024 number pop up. This means
that the default is 1024 on your system, so raising it in PHP won't
actually do anything unless you also raise it on your system. We try to
match the limit in order to give you a sensible error message instead of
your program just breaking quietly, or with a warning that doesn't tell
you that it is due to hitting a system limit.

So, in order to raise this you have to both tell your operating system
that you want to allow individual processes to open more than 1024 files
each and you have to recompile PHP with this higher limit.

Now, having said that, I don't quite understand why a single PHP cgi
process would ever need more than 1024 open files at the same time. What
exactly are you doing that needs this many descriptors? Sounds like you
have a descriptor leak there somehow.

-Rasmus

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

Re: [PHP-DEV] FD_SETSIZE warning?

[Rasmus Lerdorf]

On 01/13/2012 02:42 PM, Reindl Harald wrote:
> 
> Am 13.01.2012 17:36, schrieb Rasmus Lerdorf:
>> FD_SETSIZE is a system limit on the number of open files a
>> single process can have. From a bash shell type: ulimit -n and
>> you will probably see this magical 1024 number pop up. This
>> means that the default is 1024 on your system, so raising it in
>> PHP won't actually do anything unless you also raise it on your
>> system. We try to match the limit in order to give you a sensible
>> error message instead of your program just breaking quietly, or
>> with a warning that doesn't tell you that it is due to hitting a
>> system limit.
>> 
>> So, in order to raise this you have to both tell your operating
>> system that you want to allow individual processes to open more
>> than 1024 files each and you have to recompile PHP with this
>> higher limit.
>> 
>> Now, having said that, I don't quite understand why a single PHP
>> cgi process would ever need more than 1024 open files at the same
>> time. What exactly are you doing that needs this many
>> descriptors? Sounds like you have a descriptor leak there
>> somehow.
> 
> on "old" sysv-systems it was easy to raise this number with
> "modern" systemd-units "LimitNOFILE=3" as example is ONE simple
> line to raise this limit
> 
> it is not the job of PHP try to GUESS system-limits and define them
> on compile-time

It isn't a guess. FD_SETSIZE isn't set by PHP, but all sorts of
underlying things need to know what FD_SETSIZE is in order to work
correctly so unfortunately when you increase it you are going to need
to recompile. This isn't unique to PHP. There are some ways to hack
around this, but they are all ugly.

-Rasmus


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

Re: [PHP-DEV] salsa.lo

[Rasmus Lerdorf]

On 01/19/2012 08:20 PM, Clint M Priest wrote:
> Just updated and tried to compile, getting this:
> 
> make: *** No rule to make target 
> `/opt/php-core/trunk-accessor/ext/hash/hash_salsa.c', needed by 
> `ext/hash/hash_salsa.lo'.  Stop.
> 
> I see that commit 322421 removed the hash_salsa.c but perhaps the Makefile 
> didn't get updated?  Anyone else seeing this?

./buildconf && ./configure

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

Re: [PHP-DEV] Change bug tracker "bogus" to "not-bug"?

[Rasmus Lerdorf]

On Jan 24, 2012, at 3:47 PM, Ferenc Kovacs  wrote:

> On Wed, Jan 25, 2012 at 12:11 AM, Justin Martin  wrote:
> 
>> Hello,
>> 
>> With some frequency, I find bugs which are not "bogus", so much as they
>> are reported based on a misunderstanding. Usually this happens for
>> documentation problems, where someone has misunderstood what the
>> documentation says, or hasn't read the documentation thoroughly enough.
>> 
>> I'd like to propose simply changing the term "bogus" to "not-bug". This
>> would more politely and clearly indicate the nature of the way the bug is
>> being closed, in addition to the comment that one ordinarily leaves.
>> 
>> Those I've spoken to in php.doc agree. Any objections?
>> 
>> Thank you,
>> Justin Martin
>> 
>> 
> 
> +1 on this.
> some other alternatives which was proposed in the past:
> - Not a bug, proposed by Philip and others
> - NFF/No Fault Found, proposed by RQuadling
> 
> honorable mentions:
> - pebkac, doofus, and 'not our problem' from yawk
> - SEP (Someone else's problem) from cjones
> 

583: CNR (Could Not Reproduce)

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

Re: [PHP-DEV] Change bug tracker "bogus" to "not-bug"?

[Rasmus Lerdorf]

Ok, by popular demand I have changed "Bogus" to "Not a bug" in the bugs
tracker. The sub-status stuff we have been discussing can just be added
in the comment when you mark something as "Not a bug".  eg.
Status: Not a bug
Reason: 583 CNR

So, having done this, for the folks too skittish to mark stuff Bogus on
people, please take another look at the bug database and help us address
the outstanding bugs and mark things as "Not a bug" for the stuff that
clearly isn't. If you need more info from the bug reporter, set the
status to feedback and ask in the comment.

There are common search queries on the front page at https:bugs.php.net.
Hit the "Most recent open bugs (all)" link and start going through them.

-Rasmus

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

Re: [PHP-DEV] Uploading a patch fails...

[Rasmus Lerdorf]

On 01/27/2012 05:49 PM, Clint M Priest wrote:
> I'm trying to upload the latest getters/setters patch to: 
> https://bugs.php.net/bug.php?id=49526
> 
> I get "Uploaded file is empty or nothing was uploaded."
> 
> Is there a problem or a file size limit?  The patch file is 205k now.

Really, a 200k patch? Why is it so big?

There is a 100k limit, but the error message you are getting indicates
that you aren't actually hitting that limitation. The server config has
a 2M limit, so you should be fitting well within that. I'm not sure how
your 200k patch is hittig that "file is empty" condition in the code.

Put it somewhere else and add a link in the report. And if someone has a
lot of free time they may go read your 200k patch.

-Rasmus

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

[PHP-DEV] Symlinks in / don't work

[Rasmus Lerdorf]

Hey Dmitry, could you take a look at this one. I think this is mostly
your code and I am a bit lost in the path manipulation that is going on
here. This is bug https://bugs.php.net/51860 and it can be reproduced
from cli like this:

% cd /
% ln -s / phptest
% echo "OK" > /phpfile
% echo ' /phpinc

% php /phptest/phpinc

And you will see that it can't find /phptest/phpfile

But magically if you run it like this:

% php phptest/phpinc

it works fine.

The problem is that /phptest gets cached without the directory bit set.
And when we read it back from the cache and see it isn't a directory we
obviously don't think it can contain a file. It works in the second case
because of what is probably a secondary bug and that is that it ends up
caching //phptest instead of /phptest. So in that case there is a cache
miss on the include and it doesn't fail. However, if you add a second
include that includes another file from /phptest then the first include
would have caused /phptest to get cached and the second include will
then fail.

If you do this exact same test from /foo instead of from / then
/foo/phptest which in this case is a symlink to /foo correctly gets
cached with directory=1.

So somewhere in the while(1) loop logic in tsrm_realpath_r() we fail to
get to the point where we stat / and set the directory bit.

Obviously if someone else wants to fire up gdb to find the likely
off-by-one error that is causing this, please do.

-Rasmus

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

[PHP-DEV] latest libpcre breaks the build

[Rasmus Lerdorf]

Heads up RMs. We need to apply the patch attached to this bug:

https://bugs.php.net/bug.php?id=60986&edit=1

to 5.3/5.4/trunk. We switched to pcre_fullinfo() in most places already,
but there is that one spot left. It is essentially a one-liner and it
doesn't change any functionality since pcre_fullinfo() does exactly the
same thing as pcre_info() when called with NULL,NULL,NULL.
I have tested the patch and no tests are broken by it.

-Rasmus

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

Re: [PHP-DEV] Fwd: Re: signals hadling problem in PHP 5.4

[Rasmus Lerdorf]

On 02/14/2012 06:42 AM, Dmitry Stogov wrote:
> I've opened the bug report #61083.
> The bugs you mentioned are probably not related to zend_signals.
> They were introduced only in 5.4.

Right, but zend_signals actually fixes these deadlocks, so they are
related that way.

-Rasmus

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

Re: [PHP-DEV] Fwd: Re: signals hadling problem in PHP 5.4

[Rasmus Lerdorf]

On 02/14/2012 08:48 AM, jpauli wrote:
> On Tue, Feb 14, 2012 at 5:35 PM, Rasmus Lerdorf  <mailto:ras...@php.net>> wrote:
> 
> On 02/14/2012 06:42 AM, Dmitry Stogov wrote:
> > I've opened the bug report #61083.
> > The bugs you mentioned are probably not related to zend_signals.
> > They were introduced only in 5.4.
> 
> Right, but zend_signals actually fixes these deadlocks, so they are
> related that way.
> 
> -Rasmus
> 
> 
> Heh, that's what I suggested (without having read deeply the code).
> So even disabling zend_signals wont be a solution as those "old"
> deadlocks might happen again...

Well, you are trading one problem for another so until we can fix the
zend_signals restart issue we have to choose which of the problems we
would rather live with.

-Rasmus

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

Re: [PHP-DEV] how to debug a php script ( the C code beneath it)

[Rasmus Lerdorf]

On 02/14/2012 09:22 AM, Adi Mutu wrote:
> Thanks Julien
> 
> I don't know french, but i'll read it using google translate:)

If you just want to see some of the function calls, most calls that are
visible in userspace are prefixed with "zif_" internally.

eg.

% gdb sapi/cli/php
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
...
(gdb) b zif_strlen
Breakpoint 1 at 0x7b2760: file
/home/rasmus/php-src/branches/PHP_5_3/Zend/zend_builtin_functions.c,
line 455.
(gdb) run -r 'echo strlen("123");'
Breakpoint 1, zif_strlen (ht=1, return_value=0x1200eb0,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at
/home/rasmus/php-src/branches/PHP_5_3/Zend/zend_builtin_functions.c:455
455 {
(gdb) l
450 
451 
452 /* {{{ proto int strlen(string str)
453Get string length */
454 ZEND_FUNCTION(strlen)
455 {
456 char *s1;
457 int s1_len;

-Rasmus

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

Re: [PHP-DEV] About CVE-2012-0831 (magic_quotes_gpc remote disable vulnerability?)

[Rasmus Lerdorf]

On 02/15/2012 11:24 PM, J David wrote:
> On Tue, Feb 14, 2012 at 8:35 AM, Ferenc Kovacs  wrote:
>> as far as I can see the referenced fix (
>> http://svn.php.net/viewvc?view=revision&revision=323016) never made to the
>> 5.3.10 release (
>> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_10/?pathrev=323032&view=log
>> )
> 
> Preface: I am not expert in these matters by any means.
> 
> I happened to do some work with a build of the PHP_5_3 branch that did
> include SVN revision 323016.  With that revision, I observed some
> weird behavior with magic_quotes_gpc coming *on* even if it was
> configured off.
> 
> The specific circumstance was that magic_quotes_gpc was being set to
> off in Apache via php_flag, rather than in the .ini file.  phpinfo()
> reported magic_quotes_gpc as Off/On, but magic quotes behavior started
> happening anyway.  Of course I just moved the configuration to the
> .ini file where it belongs, but this was a change from previous
> behavior prior to that rebuild.  Maybe it was a coincidence, but when
> I saw this discussion, I felt mentioning it was "better safe than
> sorry."

There is lots of weirdness around Apache startup and double module loads
and such that makes the initialization code overly complicated, so it
doesn't surprise me that this change could have some issues. Was this
with Apache1 or 2 you saw this?

-Rasmus

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

[PHP-DEV] Re: [PECL-DEV] New PECL account request to maintain ibm_db2, pdo_ibm and pdo_informix PECL extensions

[Rasmus Lerdorf]

IBM created a bit of a mess here. We can't grant new accounts on these
extensions without the approval of one of the existing members. They
have some sort of internal process they need to go through to be allowed
to commit to this code.

The existing members are: dbs,skoduru,kraman,rs,kfbombar,tessus,ambrish

Have one of those reply here or email me privately and I will be happy
to set it up.

-Rasmus

On 02/17/2012 02:01 AM, Ferenc Kovacs wrote:
> Hi
> 
> could somebody with karma approve his svn account request and give him
> karma to the ibm_db2, pdo_ibm and pdo_informix pecl exts?
> thanks!
> 
> On Thu, Feb 16, 2012 at 9:18 AM, Rahul Priyadarshi2 <
> rahul.priyadar...@in.ibm.com> wrote:
> 
>> I have requested for SVN account on 13th Feb
>> http://old.nabble.com/SVN-Account-Request%3A-rahulpriyadarshi-tt33313124.html.
>>
>>
>> When I tried to commit a file then get the error message  "Authentication
>> realm:  PHP Subversion Repository",
>> So, it looks like my SVN account is not yet approved.
>>
>> Please approve my SVN account so that I can commit my changes to SVN and
>> make the new release.
>>
>> If more action required  from my side to get SVN account then please let
>> me know about that.
>>
>> Thanks,
>> Rahul Priyadarshi
>> India Software Lab, IBM Software Group
>>
>> Mail ID: *rahul.priyadar...@in.ibm.com* 
>> Phone(Desk): 080-402-55240
>> Cell: +91-9916422069
>>
>>
>>
>> From:Pierre Joye 
>> To:Ferenc Kovacs 
>> Cc:Rahul Priyadarshi2/India/IBM@IBMIN, Ambrish
>> Bhargava1/India/IBM@IBMIN, Hannes Magnusson ,
>> Mario Ds Briggs/India/IBM@IBMIN, pecl-...@lists.php.net, Rajesh K
>> Arora/India/IBM@IBMIN
>> Date:01/30/2012 04:49 PM
>> Subject:Re: [PECL-DEV] New PECL account request to maintain
>> ibm_db2, pdo_ibm and pdo_informix PECL extensions
>> --
>>
>>
>>
>> right, but master was down and that's why we did not approve it earlier.
>>
>> On Mon, Jan 30, 2012 at 9:15 AM, Ferenc Kovacs  wrote:
>>> hi,
>>>
>>> Rahul asked this multiple times, both on the list and on irc also.
>>> but ok, I will refrain from approving pecl accounts in the future.
>>>
>>> On Mon, Jan 30, 2012 at 1:59 AM, Pierre Joye 
>> wrote:

 hi Ferenc,

 Please do not do that. That's exacty why we have such a mess right
 now. Simply ask on IRC if you do not see an account request or let us
 deal with that.

 On Sun, Jan 29, 2012 at 1:38 PM, Ferenc Kovacs 
>> wrote:
> Hi.
>
> I opened your pecl account, but I still can't see your svn account
> request,
> we fixed the issues that we had in the last weeks, so could you fill
>> out
> the svn account request form on http://php.net/svn-php.php ?
>
> On Fri, Dec 30, 2011 at 10:12 AM, Rahul Priyadarshi2 <
> rahul.priyadar...@in.ibm.com> wrote:
>
>> I have filled up both the forms, but my account is not activated yet.
>>
>> Please let me know what next action to be required for this.
>>
>> Thanks,
>> Rahul Priyadarshi
>> India Software Lab, IBM Software Group
>>
>>
>>
>> From:Ferenc Kovacs 
>> To:Hannes Magnusson 
>> Cc:Rahul Priyadarshi2/India/IBM@IBMIN, Ambrish
>> Bhargava1/India/IBM@IBMIN, Mario Ds Briggs/India/IBM@IBMIN,
>> pecl-...@lists.php.net, Rajesh K Arora/India/IBM@IBMIN
>> Date:12/24/2011 01:46 PM
>> Subject:Re: [PECL-DEV] New PECL account request to maintain
>> ibm_db2, pdo_ibm and pdo_informix PECL extensions
>> --
>>
>>
>>
>> Hi
>>
>> the pecl account is outstanding(so it's there), I think he only needs
>> to
>> re-request an svn account under
>>  *http://www.php.net/svn-php.php*
>>
>>
>> On Sat, Dec 24, 2011 at 1:58 AM, Hannes Magnusson <*
>> hannes.magnus...@gmail.com* > wrote:
>> It didn't, please fill it out again :)
>>
>> -Hannes
>>
>> On Fri, Dec 23, 2011 at 14:27, Hannes Magnusson
>> <*hannes.magnus...@gmail.com* > wrote:
>>> Err.. The backend server is currently down.. I'll check if the
>>> application got registered once its back up.
>>>
>>> -Hannes
>>>
>>> On Fri, Dec 23, 2011 at 13:07, Rahul Priyadarshi2
>>> <*rahul.priyadar...@in.ibm.com* >
>>> wrote:
 I have filled up the application form.
 My user name is: rahulpriyadarshi

 I am an IBM developer and currently also involve in enhancing
>> these
 PECL
 extensions, so I full fill all the IBM restrictions.

 p.s. While submitting the application I got some exceptions, but
 latter
>> on
 re-submission gives error like "Sorry, that username is already
 taken"
>> and
 when tried with some other user name then got error like "username
 or
>> email
 alread

[PHP-DEV] Re: [PECL-DEV] New PECL account request to maintain ibm_db2, pdo_ibm and pdo_informix PECL extensions

[Rasmus Lerdorf]

On 02/17/2012 10:55 AM, Ambrish Bhargava1 wrote:
> Hi Rasmus,
> 
> I am one of the developer for IBM_DB2, PDO_IBM and PDO_INFORMIX
> extensions. Rahul is working with me on these extension. To contribute
> to these extensions on the community he needs SVN access to his account.

Ok, done.


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

[PHP-DEV] max_file_uploads INI_PERDIR

[Rasmus Lerdorf]

I'd like to add PHP_INI_PERDIR to max_file_uploads before 5.4.0 and also
in the next 5.3 release. This setting is very similar in scope to
max_input_vars and other POST-related limiters like upload_max_filesize,
and post_max_size all of which are PHP_INI_SYSTEM|PHP_INI_PERDIR.

The main reason is that our default for max_file_uploads is rather low
and since we count empty uploads against this limit it is easy for apps
to hit this. So if you have more than 20 type="file" fields in a form,
even if the user only actually uploads a single file, it will hit this
limit and fail.

The change it trivial and since it eases a restriction and doesn't
tighten one, it isn't going to break anything:

http://svn.php.net/viewvc/php/php-src/trunk/main/main.c?r1=323245&r2=323296

Any objections from anyone?
Stas on the 5.4.0 merge?
Johannes on the 5.3.11?

One example of pain this is currently causing:
   http://allinthehead.com/retro/349/the-curse-of-max_file_uploads

-Rasmus

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

Re: [PHP-DEV] max_file_uploads INI_PERDIR

[Rasmus Lerdorf]

On 02/17/2012 02:41 PM, Stas Malyshev wrote:
> Hi!
> 
>> I'd like to add PHP_INI_PERDIR to max_file_uploads before 5.4.0 and also
>> in the next 5.3 release. This setting is very similar in scope to
> 
> I think the change is good, I just want to understand - why before
> 5.4.0? I understand the change itself - though the problem has rather
> easy workaround, as it seems: don't put that many file uploads on the
> page if you're not using them - but why the urgency?
> 

Mostly because if we put it into 5.3.11 it creates a weird gap in the
expectations. We would have to document that it is there as of 5.3.11,
but not 5.4.0, but then again in 5.4.1.

-Rasmus

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

Re: [PHP-DEV] max_file_uploads INI_PERDIR

[Rasmus Lerdorf]

On Feb 18, 2012, at 2:33 AM, "Gustavo Lopes"  wrote:

> On Fri, 17 Feb 2012 22:59:20 +0100, Rasmus Lerdorf  wrote:
> 
> 
>> The main reason is that our default for max_file_uploads is rather low
>> and since we count empty uploads against this limit it is easy for apps
>> to hit this. So if you have more than 20 type="file" fields in a form,
>> even if the user only actually uploads a single file, it will hit this
>> limit and fail.
>> 
> 
> This is not true since PHP 5.3.4. See request #50692 (don't count 0-bytes 
> files towards the max_file_uploads limit).
> 

That's good, but it still doesn't make sense to me that the scope of this is 
different from those other related settings.

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

Re: [PHP-DEV] file_get_contents from HTTPS on Slackware 13.1

[Rasmus Lerdorf]

On 02/21/2012 06:54 AM, Bostjan Skufca wrote:
> Hi all,
> 
> we've bumped into a possible bug where file_get_contents() returns empty
> string if we try to get contents from HTTPS source. This error only occurs
> if PHP is compiled with --with-curlwrappers.
> 
> Funny thing is this only happens on slackware 13.1, but not on 13.0 or
> older. I've checked ./configure and make output and they are almost
> identical, strace does not return anything meaningful.
> Environment is highly controlled by configuration management, software is
> built in the same way, except underlying OS versions (and very basic libs
> and tools versions) differ.
> 
> Two questions:
> 1. Do any of you guys have any idea about this?
> 2. How to continue exploring deeper to discover what actually this error is
> all about?

Does a command line curl call to the same SSL URL work?

-Rasmus

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

Re: [PHP-DEV] PHP Script Compile System

[Rasmus Lerdorf]

On 02/21/2012 10:16 PM, John Crenshaw wrote:
>> -Original Message-
>> From: Deepak Balani [mailto:wgpdeepak1...@gmail.com] 
>> Sent: Wednesday, February 22, 2012 1:07 AM
>> To: flav...@php.net
>> Cc: internals@lists.php.net
>> Subject: Re: [PHP-DEV] PHP Script Compile System
>>
>> No I mean persistent compilation system like
>>
>> Java
>>
>> HelloWorld.Java -> HelloWorld.class
>>
>>
>> HelloWorld.php -> HelloWorld.gpc
>>
>> When you call
>>
>> gpc_import('HelloWorld.php');
>>
>> then function first look for HelloWorld.gpc if found then include it and if 
>> not then look for
>> HelloWorld.php or HelloWorld.inc (whatever the setting is) if found compile 
>> it and include it else
>> raise an error.
> 
> Can you explain how this is better or functionally different from the 
> behavior of APC? APC caches bytecode this way too. Unless I've horribly 
> misunderstood something, when you include the file APC uses the cached 
> bytecode as long as it is available and the file was not since modified. If 
> the file was modified APC recompiles it and caches the bytecode. Sounds like 
> the same net result to me, except that APC is less complicated, requires no 
> code changes, and automatically clears its own cache.
> 
> Did I miss something?

There is also apc_bin_dump() and apc_bin_load() if you absolutely must
have something stored on disk, but assuming you are interested in the
performance aspect here, you don't want to be loading anything from disk
on a per-request basis. If the interest is along the lines of being able
to distribute obfuscated binaries or something, then this is completely
the wrong approach because it is trivial to reverse engineer unless you
add an encryption layer on top of it.

I think one thing that people miss when comparing the php compile phase
to java/c/c++ compilation is that compiling a php script to opcodes is
super fast because we don't do complicated optimization passes or any of
those things, so the performance you gain by only skipping the
compilation phase isn't actually that much unless you combine it with
also caching the op_arrays, function and class tables in memory.

Imagine needing to compile a C++ program on every request? That just
isn't feasible. Without an opcode cache, the PHP compiler runs on every
request and it is fast enough for millions of sites out there.

-Rasmus

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