Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Rowan Collins]

Craig Francis wrote on 14/09/2015 12:46:

So yes, in the example above, an isset() would work, but I was trying to show why I don't 
think it's odd to "suppress a warning for a plain variable" when it does not 
exist.


Yes, and I agree that this example shows a reasonable use of isset(). It 
works fine as it is, and doesn't need any functionality adding or removing.




Actually, I think they do use an array to store the values, then do an 
extract() to make them local variables in the View (keeping the variable names 
shorter and easier to read).


Incidentally, I've always wondered why extract() would ever be useful in 
modern code, but I agree that if you don't want/need the overhead of a 
separate template compiler, that approach actually works quite nicely.




Yes, it is mis-used with arrays, but I would still argue that a single exists() 
function would work better for all of these examples when testing if they exist.

And I would hope that no-one was using an unset() as something distinctly 
different from a NULL value.


If you don't need the ability to distinguish unset() from null, what 
would any of these examples gain from using exists() over isset()?




I agree that we should not have a function that distinguishes between 
unset($foo) and $foo=null.


But if you take the "is null" check out of isset(), that's exactly what 
you have; that's why the "is null" check is there in the first place.


That's why I said I could agree with an exists() function (not under 
that name) as a nicer syntax for array_key_exists(), but not as a 
replacement for isset().


You could have an exists() function which works like array_key_exists() 
on an array, but identically to isset() on plain variables, but I think 
that would just be confusing. Hence my suggestion that any new function 
throw an error if given something other than an array access.


Regards,
--
Rowan Collins
[IMSoP]

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

[PHP-DEV] Bumping minimal OpenSSL version to 0.9.8

[Jakub Zelenka]

Hi,

At the moment the minimal OpenSSL version is 0.9.6.

I realised yesterday that there are some types changes between 0.9.7 and
0.9.8 that would have to be address in overflow checks (EVP_DigestUpdate
and related). I also noticed that 0.9.6 might not even compile without
warnings as it's checking return type for some function that did not return
anything in 0.9.6. We also have few other old places where we don't check
retval because of that.

The thing is that the last update for 0.9.7 stable branch is in 2008 and
0.9.6 in 2005. Both of them have been long time EOL so I don't think that
it makes any sense to spend any time on making them compatible for PHP 7.
So I think we should bump minimal version to 0.9.8.

Anatol would you be ok if this is done for 7.0? I don't think that anyone
would ever use PHP 7 and such an old version of OpenSSL together so there
should be no issue IMHO.

Cheers

Jakub

[PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP should be configured and built with --enable-huge-code-pages, OS shoul

[Dmitry Stogov]

The effect of this patch is really exiting to keep it disabled by
default... :)

$ perf stat -e instructions,iTLB-loads,iTLB-load-misses,cycles
sapi/cgi/php-cgi -d opcache.enable_huge_code_pages=0 -T 1
/var/www/html/bench/wordpress-3.6/index.php > /dev/null

   191,778,620,621  instructions  #0.81  insns per
cycle
   178,497,016
iTLB-loads
87,351,276  iTLB-load-misses  #   48.94% of all iTLB
cache hits
   238,136,402,797
cycles

 110.221114219 seconds time elapsed

$ perf stat -e instructions,iTLB-loads,iTLB-load-misses,cycles
sapi/cgi/php-cgi -d opcache.enable_huge_code_pages=1 -T 1
/var/www/html/bench/wordpress-3.6/index.php > /dev/null

   191,780,181,536  instructions  #0.83  insns per
cycle
39,017,004
iTLB-loads
41,631,359  iTLB-load-misses  #  106.70% of all iTLB
cache hits
   231,287,491,307
cycles

 107.742837269 seconds time elapsed

May be we should enable this by default in RC (may be also file cache) and
make decision based on feedback?

Thanks. Dmtiry.



On Mon, Sep 14, 2015 at 1:34 PM, Dmitry Stogov  wrote:

> Commit:669f0b39b184593e01e677360fd79b2b63058ca0
> Author:Dmitry Stogov  Mon, 14 Sep 2015
> 13:34:17 +0300
> Parents:   145708b658d0a60b738dde1a942dea9032f2f54e
> Branches:  master
>
> Link:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=669f0b39b184593e01e677360fd79b2b63058ca0
>
> Log:
> Added an experemental ability to move PHP code pages (PHP TEXT segment)
> into HUGE pages.
> PHP should be configured and built with --enable-huge-code-pages, OS
> should be configured to provide huge pages.
> It's possible to enable/disable this future in php.ini through
> opcache.enable_huge_code_pages=0/1.
> The feature was tested on Linux and provided 2% improvement on real-life
> apps, because of 2-3 times reduction in number of iTLB misses.
>
> Changed paths:
>   M  ext/opcache/ZendAccelerator.c
>   M  ext/opcache/ZendAccelerator.h
>   M  ext/opcache/config.m4
>   M  ext/opcache/zend_accelerator_module.c
>
>
> Diff:
> diff --git a/ext/opcache/ZendAccelerator.c b/ext/opcache/ZendAccelerator.c
> index 905700e..2c3d9a4 100644
> --- a/ext/opcache/ZendAccelerator.c
> +++ b/ext/opcache/ZendAccelerator.c
> @@ -2480,6 +2480,92 @@ static void accel_gen_system_id(void)
>  }
>  #endif
>
> +#ifdef HAVE_HUGE_CODE_PAGES
> +# ifndef _WIN32
> +#  include 
> +#  include 
> +#  ifndef MAP_ANON
> +#   ifdef MAP_ANONYMOUS
> +#define MAP_ANON MAP_ANONYMOUS
> +#   endif
> +#  endif
> +#  ifndef MAP_FAILED
> +#   define MAP_FAILED ((void*)-1)
> +#  endif
> +# endif
> +
> +# if defined(MAP_HUGETLB) || defined(MADV_HUGEPAGE)
> +static int accel_remap_huge_pages(void *start, size_t size, const char
> *name, size_t offset)
> +{
> +   void *ret = MAP_FAILED;
> +   void *mem;
> +   int fd;
> +
> +   fd = open(name, O_RDONLY);
> +   if (fd < 0) {
> +   return -1;
> +   }
> +   mem = mmap(NULL, size,
> +   PROT_READ,
> +   MAP_PRIVATE | MAP_FILE | MAP_POPULATE,
> +   fd, offset);
> +   if (mem == MAP_FAILED) {
> +   close(fd);
> +   return -1;
> +   }
> +
> +#ifdef MAP_HUGETLB
> +   ret = mmap(start, size,
> +   PROT_READ | PROT_WRITE | PROT_EXEC,
> +   MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED | MAP_HUGETLB,
> +   -1, 0);
> +#endif
> +#ifdef MADV_HUGEPAGE
> +   if (ret == MAP_FAILED) {
> +   ret = mmap(start, size,
> +   PROT_READ | PROT_WRITE | PROT_EXEC,
> +   MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED,
> +   -1, 0);
> +   madvise(start, size, MADV_HUGEPAGE);
> +   }
> +#endif
> +   if (ret == start) {
> +   memcpy(start, mem, size);
> +   mprotect(start, size, PROT_READ | PROT_EXEC);
> +   }
> +   munmap(mem, size);
> +   close(fd);
> +
> +   return (ret == start) ? 0 : -1;
> +}
> +
> +static void accel_move_code_to_huge_pages(void)
> +{
> +   FILE *f;
> +   long unsigned int huge_page_size = 2 * 1024 * 1024;
> +
> +   f = fopen("/proc/self/maps", "r");
> +   if (f) {
> +   long unsigned int  start, end, offset, inode;
> +   char perm[5], dev[6], name[MAXPATHLEN];
> +   int ret;
> +
> +   ret = fscanf(f, "%lx-%lx %4s %lx %5s %ld %s\n", ,
> , perm, , dev, , name);
> +   if (ret == 7 && perm[0] == 'r' && perm[1] == '-' &&
> perm[2] == 'x' && name[0] == '/') {
> +   long unsigned int  seg_start =
> ZEND_MM_ALIGNED_SIZE_EX(start, huge_page_size);
> +   long unsigned int  seg_end = (end &
> ~(huge_page_size-1L));
> +
> +   if (seg_end > seg_start) {
> +   zend_accel_error(ACCEL_LOG_DEBUG, "remap
> to huge page %lx-%lx %s \n", 

[PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP should be configured and built with --enable-huge-code-pages, OS shoul

[Xinchen Hui]

Hey:

On Mon, Sep 14, 2015 at 6:57 PM, Dmitry Stogov  wrote:
> The effect of this patch is really exiting to keep it disabled by default...
> :)
>
> $ perf stat -e instructions,iTLB-loads,iTLB-load-misses,cycles
> sapi/cgi/php-cgi -d opcache.enable_huge_code_pages=0 -T 1
> /var/www/html/bench/wordpress-3.6/index.php > /dev/null
>
>191,778,620,621  instructions  #0.81  insns per cycle
>178,497,016  iTLB-loads
> 87,351,276  iTLB-load-misses  #   48.94% of all iTLB
> cache hits
>238,136,402,797  cycles
>
>  110.221114219 seconds time elapsed
>
> $ perf stat -e instructions,iTLB-loads,iTLB-load-misses,cycles
> sapi/cgi/php-cgi -d opcache.enable_huge_code_pages=1 -T 1
> /var/www/html/bench/wordpress-3.6/index.php > /dev/null
>
>191,780,181,536  instructions  #0.83  insns per cycle
> 39,017,004  iTLB-loads
> 41,631,359  iTLB-load-misses  #  106.70% of all iTLB
> cache hits
>231,287,491,307  cycles
>
>  107.742837269 seconds time elapsed
>
> May be we should enable this by default in RC (may be also file cache) and
> make decision based on feedback?
>
For me, it is a safe improvement,  and it shouldn't break any
functions (except the perf report/anno symbols lost, which actually is
a limitation by current perf tool self , maybe it could be fixed
later).

and it give us a significant improvement,  I'd like to see it to be
enabled by default.

thanks
> Thanks. Dmtiry.
>
>
>
> On Mon, Sep 14, 2015 at 1:34 PM, Dmitry Stogov  wrote:
>>
>> Commit:669f0b39b184593e01e677360fd79b2b63058ca0
>> Author:Dmitry Stogov  Mon, 14 Sep 2015
>> 13:34:17 +0300
>> Parents:   145708b658d0a60b738dde1a942dea9032f2f54e
>> Branches:  master
>>
>> Link:
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=669f0b39b184593e01e677360fd79b2b63058ca0
>>
>> Log:
>> Added an experemental ability to move PHP code pages (PHP TEXT segment)
>> into HUGE pages.
>> PHP should be configured and built with --enable-huge-code-pages, OS
>> should be configured to provide huge pages.
>> It's possible to enable/disable this future in php.ini through
>> opcache.enable_huge_code_pages=0/1.
>> The feature was tested on Linux and provided 2% improvement on real-life
>> apps, because of 2-3 times reduction in number of iTLB misses.
>>
>> Changed paths:
>>   M  ext/opcache/ZendAccelerator.c
>>   M  ext/opcache/ZendAccelerator.h
>>   M  ext/opcache/config.m4
>>   M  ext/opcache/zend_accelerator_module.c
>>
>>
>> Diff:
>> diff --git a/ext/opcache/ZendAccelerator.c b/ext/opcache/ZendAccelerator.c
>> index 905700e..2c3d9a4 100644
>> --- a/ext/opcache/ZendAccelerator.c
>> +++ b/ext/opcache/ZendAccelerator.c
>> @@ -2480,6 +2480,92 @@ static void accel_gen_system_id(void)
>>  }
>>  #endif
>>
>> +#ifdef HAVE_HUGE_CODE_PAGES
>> +# ifndef _WIN32
>> +#  include 
>> +#  include 
>> +#  ifndef MAP_ANON
>> +#   ifdef MAP_ANONYMOUS
>> +#define MAP_ANON MAP_ANONYMOUS
>> +#   endif
>> +#  endif
>> +#  ifndef MAP_FAILED
>> +#   define MAP_FAILED ((void*)-1)
>> +#  endif
>> +# endif
>> +
>> +# if defined(MAP_HUGETLB) || defined(MADV_HUGEPAGE)
>> +static int accel_remap_huge_pages(void *start, size_t size, const char
>> *name, size_t offset)
>> +{
>> +   void *ret = MAP_FAILED;
>> +   void *mem;
>> +   int fd;
>> +
>> +   fd = open(name, O_RDONLY);
>> +   if (fd < 0) {
>> +   return -1;
>> +   }
>> +   mem = mmap(NULL, size,
>> +   PROT_READ,
>> +   MAP_PRIVATE | MAP_FILE | MAP_POPULATE,
>> +   fd, offset);
>> +   if (mem == MAP_FAILED) {
>> +   close(fd);
>> +   return -1;
>> +   }
>> +
>> +#ifdef MAP_HUGETLB
>> +   ret = mmap(start, size,
>> +   PROT_READ | PROT_WRITE | PROT_EXEC,
>> +   MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED | MAP_HUGETLB,
>> +   -1, 0);
>> +#endif
>> +#ifdef MADV_HUGEPAGE
>> +   if (ret == MAP_FAILED) {
>> +   ret = mmap(start, size,
>> +   PROT_READ | PROT_WRITE | PROT_EXEC,
>> +   MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED,
>> +   -1, 0);
>> +   madvise(start, size, MADV_HUGEPAGE);
>> +   }
>> +#endif
>> +   if (ret == start) {
>> +   memcpy(start, mem, size);
>> +   mprotect(start, size, PROT_READ | PROT_EXEC);
>> +   }
>> +   munmap(mem, size);
>> +   close(fd);
>> +
>> +   return (ret == start) ? 0 : -1;
>> +}
>> +
>> +static void accel_move_code_to_huge_pages(void)
>> +{
>> +   FILE *f;
>> +   long unsigned int huge_page_size = 2 * 1024 * 1024;
>> +
>> +   f = fopen("/proc/self/maps", "r");
>> +   if (f) {
>> +   long unsigned int  start, end, offset, inode;
>> +   char perm[5], dev[6], name[MAXPATHLEN];
>> +   int ret;
>> +

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Craig Francis]

On 9 Sep 2015, at 19:34, Rowan Collins  wrote:

> Craig Francis wrote on 09/09/2015 16:54:
>> I don't think it is an odd thing to suppress a warning for a plain variable.
>> 
>> For example, on a blog you may have a list of articles, which is used by 
>> both the admin and users, but the (MVC) controller might set an $add_url, so 
>> a link to add a new article can be displayed...
>> 
>> Controller:
>> 
>> if (IS_ADMIN) {
>>  $this->set('add_url', '/admin/articles/add/');
>> }
>> 
>> View:
>> 
>> 
>>  Add article
>> 
> 
> I can see that this makes nice terse View code, and is a reasonable use of 
> existing isset() - though I can't see it needs to be anything other than 
> isset(), because if $add_url was null, you wouldn't want to echo anything.
> 
> Arguably, it would be better handled with the vars placed into an array 
> rather than materialising as PHP variables. The helper functions defined by 
> the framework (here assumed to be called exists() and html()) could then 
> extract items from that array, making it just as succinct:
> 
>
>   Add article
>
> 
> 
> Boom, no more worries about undefined variables.



It depends, the exists() was simply to show the proposed function in place, and 
html() was more to show a cut down version of htmlentitites.

Most frameworks I've used typically have plain variables in the View 
(templating engines are a bit different)... but I have used a $v[] array on my 
own project before (many years ago), but it got quite ugly... especially when 
it's often passing multi-dimentional arrays (or objects) into the View.

So yes, in the example above, an isset() would work, but I was trying to show 
why I don't think it's odd to "suppress a warning for a plain variable" when it 
does not exist.



> I'm pretty sure this is how templating languages like Smarty and Twig work - 
> "{$foo}" in Smarty compiles to something like "echo $this->vars['foo'];"
> 
> Presumably under the hood, the set() method in your example has to instead do 
> some magic with variable variables - $$foo syntax - which is like the ugly 
> cousin of an associative array. Either that, or eval(), which as everyone 
> knows is evil()! :P



Actually, I think they do use an array to store the values, then do an 
extract() to make them local variables in the View (keeping the variable names 
shorter and easier to read).

The code I'm looking at today uses a function to include the View, such as:

function script_run() {
if (func_num_args() > 1) {
extract(func_get_arg(1));
}
require(func_get_arg(0));
}

script_run($view_path, $variables);



>> But, the thing that wins it over for me is that isset() seems to be 
>> (mis)used by a lot of developers as a function to check if the variable 
>> exists (not that the variable has a value).
> 
> Do you mean that it is misused with arrays? Because with plain variables it 
> does exactly what it needs to do.
> 
> Or do you mean that developers are using unset() to represent a state 
> distinct from null? Because if so, that is their mistake, not the subsequent 
> use of isset(). I have yet to see a single use case where distinguishing 
> between these two states is necessary or sensible.



Yes, it is mis-used with arrays, but I would still argue that a single exists() 
function would work better for all of these examples when testing if they exist.

And I would hope that no-one was using an unset() as something distinctly 
different from a NULL value.



>> Actually, in a few years time, if developers did their NULL checks with "=== 
>> NULL", then isset(), is_null(), array_key_exists(), and empty() could all be 
>> deprecated :-)
> 
> - is_null() makes sense because it's a type-checking function: it goes with 
> is_bool(), is_int(), etc.
> - empty() is a bit odd because it's basically an inverted boolean cast, but 
> does make quite readable code.
> - You've just demonstrated yourself a situation where isset() can't be 
> replaced with === null or is_null() because you want to suppress the Notice.
> - I am fundamentally opposed to a function which distinguishes between 
> unset($foo) and $foo=null for reasons I have stated several times.
> 
> So the only thing left is replacing array_key_exists with some nicer syntax 
> so you can write some_keyword($foo['bar']) rather than 
> array_key_exists('bar', $foo)



I agree that we should not have a function that distinguishes between 
unset($foo) and $foo=null.

But I believe the isset() function is often used just to see if the variable 
exists (i.e. avoiding the undefined variable notice), and having the extra "and 
is not NULL" logic does not help in this situation.

It's just the "and is not NULL" logic causing problems when the developer 
should be using array_key_exists.



So if we look at it from the point of view of "lets kill isset" (just humour me 
for a 

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Rowan Collins]

Craig Francis wrote on 14/09/2015 16:57:

Hi Rowan,

I think I've said everything I can from my point of view (and my understanding 
of how other developers see and use the isset function).

And that's not to say I disagree with what your saying Rowan, I'm just voicing 
my view that I think a language with exists() would be nicer than the slightly 
messy isset()... but each to their own.

Maybe Scott (who proposed the idea) might follow up with more information?

Otherwise I'm off on holiday, see you in a few weeks :-)


Yes, I think we're going round in circles at this point, and should see 
if anyone else has an opinion that would move the discussion forward.


Have a nice holiday! :)

Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Craig Francis]

Hi Rowan,

I think I've said everything I can from my point of view (and my understanding 
of how other developers see and use the isset function).

And that's not to say I disagree with what your saying Rowan, I'm just voicing 
my view that I think a language with exists() would be nicer than the slightly 
messy isset()... but each to their own.

Maybe Scott (who proposed the idea) might follow up with more information?

Otherwise I'm off on holiday, see you in a few weeks :-)

Craig





On 14 Sep 2015, at 13:09, Rowan Collins  wrote:

> Craig Francis wrote on 14/09/2015 12:46:
>> So yes, in the example above, an isset() would work, but I was trying to 
>> show why I don't think it's odd to "suppress a warning for a plain variable" 
>> when it does not exist.
> 
> Yes, and I agree that this example shows a reasonable use of isset(). It 
> works fine as it is, and doesn't need any functionality adding or removing.
> 
> 
>> Actually, I think they do use an array to store the values, then do an 
>> extract() to make them local variables in the View (keeping the variable 
>> names shorter and easier to read).
> 
> Incidentally, I've always wondered why extract() would ever be useful in 
> modern code, but I agree that if you don't want/need the overhead of a 
> separate template compiler, that approach actually works quite nicely.
> 
> 
>> Yes, it is mis-used with arrays, but I would still argue that a single 
>> exists() function would work better for all of these examples when testing 
>> if they exist.
>> 
>> And I would hope that no-one was using an unset() as something distinctly 
>> different from a NULL value.
> 
> If you don't need the ability to distinguish unset() from null, what would 
> any of these examples gain from using exists() over isset()?
> 
> 
>> I agree that we should not have a function that distinguishes between 
>> unset($foo) and $foo=null.
> 
> But if you take the "is null" check out of isset(), that's exactly what you 
> have; that's why the "is null" check is there in the first place.
> 
> That's why I said I could agree with an exists() function (not under that 
> name) as a nicer syntax for array_key_exists(), but not as a replacement for 
> isset().
> 
> You could have an exists() function which works like array_key_exists() on an 
> array, but identically to isset() on plain variables, but I think that would 
> just be confusing. Hence my suggestion that any new function throw an error 
> if given something other than an array access.
> 
> Regards,
> -- 
> Rowan Collins
> [IMSoP]


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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Stanislav Malyshev]

Hi!

> I’m not sure what a good solution is, however. Changing isset()
> will have consequences: making it return true for null will
> magically fix a

No. There's no reason for null to exist if isset returns true on null.
If one doesn't understand that, one should not be using null at all.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] taint

[Christopher Owen]

> On Sep 14, 2015, at 1:35 PM, Kalle Sommer Nielsen  wrote:
> 
> Hi Christopher
> 
> 2015-09-14 4:44 GMT+02:00 Christopher Owen :
>> Please consider making ‘taint’ a first-class feature/extension in PHP 7.0.
> 
> It is way too late for any extension to be included in the 7.0 release
> now, but you can write an RFC targetting 7.1, please see the wiki for
> more details[1].

Thank you for the advice; it makes much more sense to target 7.1.

We can see that Wietse Venema; the same man who wrote the highly regarded, 
security hardened email software Postfix; has authored an RFC for taint's 
inclusion to PHP the past [1].  Also, a reference implementation has been most 
recently championed by Xinchen (Laruence) Hui, a core php developer [2].

Given those that came before me, I’m not certain that I can add much in the way 
of reputation or skill to the request to add taint as a first-class feature of 
PHP 7.1, but if there are any procedural efforts required then I will be happy 
to champion them.

I can add that I have personally found taint (either in its original form in 
perl[3] or as an extension in php) a valuable tool in refactoring legacy php 
code to reduce SQL injection attack surface.

As authorative internet ‘top ten’ lists will list SQL injection as the number 
one security vulnerability facing web applications [4] and given the scale of 
deployed php, efforts to improve tooling (or in this case, the availability of 
existing tooling) to discover this class of vulnerabilities will have a 
positive impact on a global scale.

Kind regards,
 Christopher Owen.

[1] https://wiki.php.net/rfc/taint 
[2] http://pecl.php.net/package/taint  
[3] http://perldoc.perl.org/perlsec.html#Taint-mode 

[4] http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf 

RE: [PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP should be configured and built with --enable-huge-code-pages, OS s

[Anatol Belski]

> -Original Message-
> From: Dmitry Stogov [mailto:dmi...@zend.com]
> Sent: Monday, September 14, 2015 10:37 PM
> To: Anatol Belski 
> Cc: Anatol Belski ; Kalle Sommer Nielsen ;
> Rasmus Lerdorf ; Xinchen Hui ;
> Nikita Popov ; Zeev Suraski ; Andi
> Gutmans ; PHP Internals 
> Subject: Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental
> ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP
> should be configured and built with --enable-huge-code-pages, OS should be
> configured to provide huge pages. It's possibl
> 
> >
> > With the new huge memory pages feature I'd suggest a bit softer -
> > enabling its building, but setting opcache.enable_huge_code_pages=0 by
> default.
> 
> 
> OK.
> 
> 
> > Then it can be easy enable and give one more intermediate step for pre
> > testing and go into RC4 completely if ok.
> 
> 
> In general we may get build problems on some platforms...
> 
> 
> > What do you think?
> >
> 
> I didn't get, do you like to delay this for RC4? or enable it at compile time 
> and
> disable at run-time by default for RC3?
> I agree with both.
> 
I was suggesting the latter - build and disable at run-time. With RC4 I meant - 
as it's run-time enabled by default currently, that could be turned on by 
default in RC4 if everything was well in RC3.

Regarding possible build issues you mention - probably some magic in config.m4 
could disable huge pages? I wasn't aware, but probably yep - like FreeBSD or 
OSX likely to not to have the sys/prctl.h . This could be a reason for delaying 
till RC4, but it's actually easy solved doing some test compilation in 
config.m4 . I'd see build + disable on run-time in RC3 as a better move because 
it turns the test circle earlier which is good considering there are only 4 RCs 
to go yet.

Regards

Anatol


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

Re: [PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

[Daniel Persson]

I've read some of the earlier discussion (not all, require sleep will read
more tomorrow).

To be clear I don't want to start a naming discussion again. If we have a
new name for $_POST or not isn't the main focus of this PR.

I want to allow PUT, PATCH and DELETE and handle them the same way as POST
so we get populated globals with data we could later filter and use.

Most of the frameworks work around this limitation in the core so I thought
it might be in place to suggest we allow these request methods.

On Mon, Sep 14, 2015 at 11:38 PM, Ryan Pallas  wrote:

>
>
> On Mon, Sep 14, 2015 at 3:22 PM, Daniel Persson 
> wrote:
>
>> Hi.
>>
>> I've not been a member for too long so I might have missed if this have
>> been discussed earlier.
>>
>> But I've created a small PR to the basic request handling to support PUT,
>> PATCH and DELETE.
>>
>> https://github.com/php/php-src/pull/1519
>>
>> Summary:
>>
>> Added support for request methods with the smallest change possible.
>> History:
>>
>> HTTP 1.0 had only support for GET, POST and HEAD.
>> In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010
>> RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH.
>> Pull request explaination:
>>
>> In this pull request I try to add put, patch and delete with changing as
>> few functions as possible. I simply handle the new verbs as POST. As
>> defined in HTTP 1.1 they are similar in input data requirements and differ
>> only in usage.
>>
>
> +1 from me, would love to see the verbs supported more fully. (though my
> approval means quite literally nothing). How does this affect something
> like the ini settings for variable order? IE. does GPC change from GET ->
> POST -> COOKIE to GET -> PARSED_INPUT -> COOKIE? Since only a single verb
> is available for any single request, this makes the most sense for me.
>
>
>>
>> More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE
>> but
>> I think this might be more confusing. Or we could move from $_POST to a
>> new
>> global not tied to a verb. Example $_PARSED_INPUT
>
>
> As for having a new $_PARSED_INPUT, I'm not sure I like this for 2 reasons
> a) the name is 2 words, all other super globals are single words (unless
> there's one I do not know of) and b) It feels like too long a name, sure in
> an IDE it will auto-complete for us, but for quick edits in vim for
> example, this name would suck. But my only problem with it is on a name
> level, about about just $_INPUT or does this seem to conflict with
> $_REQUEST which holds multiple super globals worth of data already.
>

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Stanislav Malyshev]

Hi!

>> No. There's no reason for null to exist if isset returns true on 
>> null. If one doesn't understand that, one should not be using
>> null at all.
> 
> 
> Nonsense.

Oh, thank you! That's a good start for a polite argument.

> It just means that one isn’t using null the way you do.

No, it means one isn't using null the way it is intended to be used in
the language. Which is your right, but then please don't demand language
to change when it doesn't work as you expected. You voided the warranty,
you bear the consequences.

> Programmers have been using null like this for decades, e.g., C 
> strings. It’s also quite common in databases, where, at least with

PHP is not C, in fact C does not have null value (akin to PHP's one)
at all. C has zero-valued pointer which is sometimes used as "no
value" in certain contexts but the semantics of how C and PHP works in
this area are completely different.

> MySQL, null happens to translate directly to PHP null when data
> are queried. And frankly, I see nothing wrong with recognizing that
> a

SQL null is not a regular value, and you are in for big surprises if
you try to use it as a regular value. PHP has much less surprises, but
if you know what NULL is in SQL, you should not be surprised by PHP's
null behavior.

> functions do. As I said, they’re misguided, right up there with 
> register_globals. (They lead to similar security bugs, too.)

Please do not bring "security" as some superman-argument, expecting
that is you say "security" your arguments suddenly become so much
stronger. There's no special security problem here besides the trivial
fact that if you write buggy code in security-sensitive context, you
get security issue. So please leave security out of it.

> Incidentally, what’s the difference, philosophically, between
> these two:
> 
> $foo = null; var_dump(isset($foo)); //false
> 
> $foo = [‘bar’ => null]; var_dump(array_key_exists(‘bar’, $foo)); 
> //true

The first is declaring variable to special value (null) that is
designed to return "empty" on isset/empty check. The second is
defining array key holding the same value. That's the difference. I'm
not sure what philosophical school you belong to, so I can't go there,
but in PHP that's pretty much it.

> If a variable that’s declared yet defined as null can’t “exist” as 
> decided by isset(), why can an array element that’s declared yet 
> defined as null “exist” as decided by array_key_exists()? Is the

Because these are two different functions doing different things.
That's like asking why strlen returns string length but fopen does not
return file length.

> symbol table really that different from an array? It gets weirder
> yet where the two start to overlap in user land:
> 
> $foo = null; var_dump(isset($foo)); //false 
> var_dump(array_key_exists('foo', $GLOBALS)); //true

What's weird in it? GLOBALS is specifically created construct to treat
global scope variables as array.

> I don’t understand how anyone can see this as being consistent and 
> self-explanatory, especially if we assume the words ‘exists’ and 
> ‘set’ to have their traditional programming meanings (‘set’
> meaning to assign a value and ‘exists’ meaning there’s an in-scope
> entry with the given name in the symbol table).

That's not what isset() does, however. As I already mentioned, null is
a special value with special semantics. If you insist on ignoring this
semantics, fine, but it's not PHP's fault then that you are surprised
by the result.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

[S.A.N]

+1 Yes, it is useful to have in the PHP core.
Possible names: $_BODY, $_DATA, $_INPUT, $_REQUEST

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

Re: [PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

[Ryan Pallas]

On Mon, Sep 14, 2015 at 3:22 PM, Daniel Persson 
wrote:

> Hi.
>
> I've not been a member for too long so I might have missed if this have
> been discussed earlier.
>
> But I've created a small PR to the basic request handling to support PUT,
> PATCH and DELETE.
>
> https://github.com/php/php-src/pull/1519
>
> Summary:
>
> Added support for request methods with the smallest change possible.
> History:
>
> HTTP 1.0 had only support for GET, POST and HEAD.
> In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010
> RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH.
> Pull request explaination:
>
> In this pull request I try to add put, patch and delete with changing as
> few functions as possible. I simply handle the new verbs as POST. As
> defined in HTTP 1.1 they are similar in input data requirements and differ
> only in usage.
>

+1 from me, would love to see the verbs supported more fully. (though my
approval means quite literally nothing). How does this affect something
like the ini settings for variable order? IE. does GPC change from GET ->
POST -> COOKIE to GET -> PARSED_INPUT -> COOKIE? Since only a single verb
is available for any single request, this makes the most sense for me.


>
> More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE but
> I think this might be more confusing. Or we could move from $_POST to a new
> global not tied to a verb. Example $_PARSED_INPUT


As for having a new $_PARSED_INPUT, I'm not sure I like this for 2 reasons
a) the name is 2 words, all other super globals are single words (unless
there's one I do not know of) and b) It feels like too long a name, sure in
an IDE it will auto-complete for us, but for quick edits in vim for
example, this name would suck. But my only problem with it is on a name
level, about about just $_INPUT or does this seem to conflict with
$_REQUEST which holds multiple super globals worth of data already.

RE: [PHP-DEV] Bumping minimal OpenSSL version to 0.9.8

[Anatol Belski]

Hi Jakub,

> -Original Message-
> From: jakub@gmail.com [mailto:jakub@gmail.com] On Behalf Of Jakub
> Zelenka
> Sent: Monday, September 14, 2015 2:04 PM
> To: PHP internals list ; Anatol Belski
> 
> Subject: [PHP-DEV] Bumping minimal OpenSSL version to 0.9.8
> 
> Hi,
> 
> At the moment the minimal OpenSSL version is 0.9.6.
> 
> I realised yesterday that there are some types changes between 0.9.7 and
> 0.9.8 that would have to be address in overflow checks (EVP_DigestUpdate and
> related). I also noticed that 0.9.6 might not even compile without warnings as
> it's checking return type for some function that did not return anything in 
> 0.9.6.
> We also have few other old places where we don't check retval because of that.
> 
> The thing is that the last update for 0.9.7 stable branch is in 2008 and
> 0.9.6 in 2005. Both of them have been long time EOL so I don't think that it
> makes any sense to spend any time on making them compatible for PHP 7.
> So I think we should bump minimal version to 0.9.8.
> 
> Anatol would you be ok if this is done for 7.0? I don't think that anyone 
> would
> ever use PHP 7 and such an old version of OpenSSL together so there should be
> no issue IMHO.
> 
0.9.8 as the lowest supported OpenSSL sounds plausible to me. Despite the 
OpenSSL team announcend EOL of the 0.9.8 and 1.0.0 series for the end of this 
year, distributions like CentOS will support it probably even longer (but not 
sure how they keep their 0.9.8 builds secure after its official EOL, probably 
some painful backporting). Fe Debian old stable has OpenSSL 1.0.1. Still 0.9.8 
were a plausible option for today's situation, IMHO. Maybe it can be raised 
once more at the PHP 7.1 times, but that's something to see then. If there are 
no objections, raising the requirement to 0.9.8 should be done for 7.0

Regards

Anatol


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

[PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

[Daniel Persson]

Hi.

I've not been a member for too long so I might have missed if this have
been discussed earlier.

But I've created a small PR to the basic request handling to support PUT,
PATCH and DELETE.

https://github.com/php/php-src/pull/1519

Summary:

Added support for request methods with the smallest change possible.
History:

HTTP 1.0 had only support for GET, POST and HEAD.
In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010
RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH.
Pull request explaination:

In this pull request I try to add put, patch and delete with changing as
few functions as possible. I simply handle the new verbs as POST. As
defined in HTTP 1.1 they are similar in input data requirements and differ
only in usage.

More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE but
I think this might be more confusing. Or we could move from $_POST to a new
global not tied to a verb. Example $_PARSED_INPUT

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[François Laupretre]

Le 14/09/2015 22:17, Robert Williams a écrit :


I’m not sure what a good solution is, however. Changing isset() will
have consequences: making it return true for null will magically fix a
lot of bugs out there, but it’ll also break code where the programmer
understood how it really works. Adding a parameter to control it is
ugly. Extending defined() to variables might be a good choice, as it’s
already doing for constants exactly what’s needed for variables; the
only downside is that it would be better-named declared() than
defined(), but that’s the case for constants, too, so I can live with
it. For now, isset() and empty() can continue to work as-is but perhaps
with a notice and deprecation when used with undeclared variables.


Going back in time and changing isset() behavior is not an option, even 
if I'd personally prefer considering a null variable as 'set'. You may 
be right and it may fix a lot of bugs, but, IMHO, you'd rather forget 
it. The same with adding a second argument.


I'd love extending defined() to support defined($var) but it would be 
ambiguous because it already means: 'get the string contained in $var 
and check if a constant with that name exists'. So, we can't use it this 
way.


IMO, the best solution is the exists() construct.

Regards

François


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

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP should be configured and built with --enable-huge-code-pages, OS s

[Rasmus Lerdorf]

On 09/14/2015 02:13 PM, Anatol Belski wrote:
> 
> 
>> -Original Message-
>> From: Dmitry Stogov [mailto:dmi...@zend.com]
>> Sent: Monday, September 14, 2015 10:37 PM
>> To: Anatol Belski 
>> Cc: Anatol Belski ; Kalle Sommer Nielsen ;
>> Rasmus Lerdorf ; Xinchen Hui ;
>> Nikita Popov ; Zeev Suraski ; Andi
>> Gutmans ; PHP Internals 
>> Subject: Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental
>> ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP
>> should be configured and built with --enable-huge-code-pages, OS should be
>> configured to provide huge pages. It's possibl
>>
>>>
>>> With the new huge memory pages feature I'd suggest a bit softer -
>>> enabling its building, but setting opcache.enable_huge_code_pages=0 by
>> default.
>>
>>
>> OK.
>>
>>
>>> Then it can be easy enable and give one more intermediate step for pre
>>> testing and go into RC4 completely if ok.
>>
>>
>> In general we may get build problems on some platforms...
>>
>>
>>> What do you think?
>>>
>>
>> I didn't get, do you like to delay this for RC4? or enable it at compile 
>> time and
>> disable at run-time by default for RC3?
>> I agree with both.
>>
> I was suggesting the latter - build and disable at run-time. With RC4 I meant 
> - as it's run-time enabled by default currently, that could be turned on by 
> default in RC4 if everything was well in RC3.
> 
> Regarding possible build issues you mention - probably some magic in 
> config.m4 could disable huge pages? I wasn't aware, but probably yep - like 
> FreeBSD or OSX likely to not to have the sys/prctl.h . This could be a reason 
> for delaying till RC4, but it's actually easy solved doing some test 
> compilation in config.m4 . I'd see build + disable on run-time in RC3 as a 
> better move because it turns the test circle earlier which is good 
> considering there are only 4 RCs to go yet.

As long as we fail gracefully when compiled with hugepage support and
then run on a system that doesn't have any hugepages configured. These
days the build box and the production execution box are rarely the same
machine.

Redhat enables THP by default and has for a while, but I know lots of
admins that disable this feature right away on production machines. I
don't think it is default on Ubuntu, but at least they have hugepage
tools to make it easy to configure. And from a quick look at Debnian
(jessie) it wasn't obvious how to get hugepages working. I don't see a
package for hugeadm offhand. The kernel supports it, obviously, but you
need to take some steps to configure them.

Which means we also need to spend a bit of time documenting how to
enable hugepages at the OS level for the various operating systems to go
along with this feature.

-Rasmus



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] HTTP/2 Server Push support in ext/curl

[Davey Shafik]

Hey all,

I'm trying to work up a patch for ext/perl to allow the
CURLMOPT_PUSHFUNCTION and CURLMOPT_PUSHDATA options, which allow for HTTP/2
Server Push.

PUSHFUNCTION allow you to register a callback that can accept/reject an
HTTP/2 server push by returning either CURL_PUSH_OK (0), or CURL_PUSH_DENY
(1)

PUSHDATA allows you to pass in a pointer that is passed straight into the
callback untouched.

So, I'm wondering a few things:

1) Should it be possible to register _multiple_ callbacks, if so we'd need
something like CURL_PUSH_PASSTHRU or some such to indicate it should move
to the next callback in the chain. This obviously differs from the libcurl
behavior, perhaps something to bring back to libcurl though? It would allow
different callbacks for say, different content types (if that's available
in the request, not sure yet :P)

1.1) If we allow multiples, do we allow removing them, what does that API
look like?

2) For PUSHDATA would we pass through a referenced user land variable? or
do we just ignore this feature?

My thinking on implementation was to have curl_multi_setopt store the
callback[s] (not sure where?), and have a fixed _php_curl_pushfunction
function that would be registered as the callback for libcurl, and would
just pass it's arguments through to the callback[s].

The issue with this is that I need to figure out stuff like the push
headers being passed through. There are two functions
curl_pushheader_bynum() and curl_pushheader_byname() which are meant to be
used to access the struct that contains the headers, so I figured I can
expose those two functions in user land, and I guess make the headers a
resource that is passed into the callback?

The alternative seems to be to resolve that in the extension and pass
through an array or something?

I'd rather not be creating _new_ resources, but ext/curl obviously has a
precedence of using them, so it would fit the UX.

Any thoughts? I'd love to get this into PHP 7.1 (or before, if possible!).

Thanks,

- Davey

[PHP-DEV] PHP-7.0 branched

[Anatol Belski]

Hi,

As was announced a couple of months ago, PHP 7.0 should get its own branch
when PHP 5.4 goes EOL. 5.4 has reached its EOL today, thus PHP-7.0 was just
branched out.

This means,  it turns back to the usual commit workflow. As of now, any
patches targeting 7.0 have to be merged into PHP-7.0 and then into master.
In general, there are two commit flows for the normal bug fixing in the
active branches ATM

7.0 => master
5.6 => 7.0 => master

The documentation regarding the git process, as well as bugs.php.net and
lxr.php.net will be updated soon.

The NEWS file in master should contain the entries relevant for master only.
The entries relevant to PHP 7.0 should go into NEWS in the PHP-7.0 branch,
not into master anymore.

Regards

Anatol


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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Robert Williams]

I really don’t understand the resistance to this type of change, other than 
knowing that a fix will necessarily be messy. The fact is, PHP distinguishes 
between a variable that has been declared but defined to null and one that 
hasn’t been declared. The value of the first may safely be assigned, compared, 
referenced, and so on, while attempting any of those things on the second one 
results in an error message. The question of whether relying on those 
differences is philosophically acceptable is a moot point: they *are* 
different, period, and the rest of the language should acknowledge and support 
that — just as do most other languages with a similar design (e.g., JavaScript).

Beyond that, the philosophical debate is clearly settled in the real world of 
code. One glance through the comments on the isset() documentation page, not to 
mention the bug reports and the discussions on the lists, shows that people 
have long struggled with this. Based on code I’ve seen from fairly experienced 
developers, the confusion around this has probably led to millions of 
production bugs, many of them in the areas of validation and security. When a 
particular aspect of a language's design promotes bugs to such an extent, it 
needs to be revisited.

I’m not sure what a good solution is, however. Changing isset() will have 
consequences: making it return true for null will magically fix a lot of bugs 
out there, but it’ll also break code where the programmer understood how it 
really works. Adding a parameter to control it is ugly. Extending defined() to 
variables might be a good choice, as it’s already doing for constants exactly 
what’s needed for variables; the only downside is that it would be better-named 
declared() than defined(), but that’s the case for constants, too, so I can 
live with it. For now, isset() and empty() can continue to work as-is but 
perhaps with a notice and deprecation when used with undeclared variables.

--
Bob W.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP should be configured and built with --enable-huge-code-pages, OS s

[Dmitry Stogov]

On Mon, Sep 14, 2015 at 11:05 PM, Anatol Belski 
wrote:

> Hi Dmitry,
>
> > -Original Message-
> > From: Dmitry Stogov [mailto:dmi...@zend.com]
> > Sent: Monday, September 14, 2015 12:58 PM
> > To: Anatol Belski ; Kalle Sommer Nielsen ;
> > Rasmus Lerdorf ; Xinchen Hui ;
> > Nikita Popov ; Zeev Suraski ; Andi
> > Gutmans ; PHP Internals 
> > Subject: [PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental
> ability
> > to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP should be
> > configured and built with --enable-huge-code-pages, OS should be
> configured to
> > provide huge pages. It's possible to
> >
> > The effect of this patch is really exiting to keep it disabled by
> default... :)
> >
> > $ perf stat -e instructions,iTLB-loads,iTLB-load-misses,cycles
> > sapi/cgi/php-cgi -d opcache.enable_huge_code_pages=0 -T 1
> > /var/www/html/bench/wordpress-3.6/index.php > /dev/null
> >
> >191,778,620,621  instructions  #0.81  insns per
> > cycle
> >178,497,016
> > iTLB-loads
> > 87,351,276  iTLB-load-misses  #   48.94% of all iTLB
> > cache hits
> >238,136,402,797
> > cycles
> >
> >  110.221114219 seconds time elapsed
> >
> > $ perf stat -e instructions,iTLB-loads,iTLB-load-misses,cycles
> > sapi/cgi/php-cgi -d opcache.enable_huge_code_pages=1 -T 1
> > /var/www/html/bench/wordpress-3.6/index.php > /dev/null
> >
> >191,780,181,536  instructions  #0.83  insns per
> > cycle
> > 39,017,004
> > iTLB-loads
> > 41,631,359  iTLB-load-misses  #  106.70% of all iTLB
> > cache hits
> >231,287,491,307
> > cycles
> >
> >  107.742837269 seconds time elapsed
> >
> > May be we should enable this by default in RC (may be also file cache)
> and make
> > decision based on feedback?
> >
> The file cache feature has proven itself as stable already, IMHO it should
> be built by default in RC3.
>

OK.


>
> With the new huge memory pages feature I'd suggest a bit softer - enabling
> its building, but setting opcache.enable_huge_code_pages=0 by default.


OK.


> Then it can be easy enable and give one more intermediate step for pre
> testing and go into RC4 completely if ok.


In general we may get build problems on some platforms...


> What do you think?
>

I didn't get, do you like to delay this for RC4? or enable it at compile
time and disable at run-time by default for RC3?
I agree with both.

Thanks. Dmitry.


>
> Regards
>
> Anatol
>
>

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Robert Williams]

On Sep 14, 2015, at 13:23, Stanislav Malyshev  wrote:
> 
> No. There's no reason for null to exist if isset returns true on null.
> If one doesn't understand that, one should not be using null at all.


Nonsense. It just means that one isn’t using null the way you do. You’re saying 
people shouldn’t be programming to distinguish between 
declared-but-defined-null and undeclared. But the fact is, from user land-POV, 
null *is* a value, and it’s frequently used where a variable needs to be 
defined with a sentinel value that clearly flags the variable as not having an 
otherwise valid value. The alternative is to use magic values as sentinels 
instead — e.g., 0 or  for an integer, or empty-string for a string — but 
that causes all sorts of bugs when those values are only rarely legitimate 
versus never legitimate (see: Y2K). Magic values also tend to make code less 
readable.

Programmers have been using null like this for decades, e.g., C strings. It’s 
also quite common in databases, where, at least with MySQL, null happens to 
translate directly to PHP null when data are queried. And frankly, I see 
nothing wrong with recognizing that a variable exists in the symbol table but 
has no real value versus one that doesn’t even exist. It’s like the difference 
between having a car in your garage that is out of gas versus not having a car 
at all.

And again, PHP itself clearly distinguishes the two states everywhere but in 
isset() and empty(). IMHO, isset() and empty() are both misguided (beyond the 
null problem) because they attribute meaning to certain values of user land 
data, and they bundle several checks together. And they do all that without any 
domain knowledge controlling what values are or are not valid. If I’m counting 
eggs in my basket, zero is most definitely a valid value, while it’s not if I’m 
looking at the weight of a specific egg. PHP shouldn’t be making that decision 
for me in blanket form. Yet, that’s exactly what these functions do. As I said, 
they’re misguided, right up there with register_globals. (They lead to similar 
security bugs, too.)

Incidentally, what’s the difference, philosophically, between these two:

$foo = null;
var_dump(isset($foo)); //false

$foo = [‘bar’ => null];
var_dump(array_key_exists(‘bar’, $foo)); //true

If a variable that’s declared yet defined as null can’t “exist” as decided by 
isset(), why can an array element that’s declared yet defined as null “exist” 
as decided by array_key_exists()? Is the symbol table really that different 
from an array? It gets weirder yet where the two start to overlap in user land:

$foo = null;
var_dump(isset($foo)); //false
var_dump(array_key_exists('foo', $GLOBALS)); //true

$array = ['foo' => null];
$bar = null;
extract($array);
print_r(get_defined_vars()); //now have both $foo and $bar in scope

I don’t understand how anyone can see this as being consistent and 
self-explanatory, especially if we assume the words ‘exists’ and ‘set’ to have 
their traditional programming meanings (‘set’ meaning to assign a value and 
‘exists’ meaning there’s an in-scope entry with the given name in the symbol 
table).

--
Bob W.


signature.asc
Description: Message signed with OpenPGP using GPGMail

[PHP-DEV] Benchmark Results for PHP Master 2015-09-14

[lp_benchmark_robot]

Results for project php-src-nightly, build date 2015-09-14 05:00:00+03:00
commit: fe08b933e4ab380d4b07275384226b688f82eeac
revision_date:  2015-09-13 12:35:35+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 
2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0beta3, with hash 
1674bd9b151ff389fb8c9fc223bc6aafdd49ff2c from 2015-08-05 04:56:40+00:00

--
 benchmark executable   relative   change since   
change since
std_dev*   last run 
php-7.0.0beta3
--
:-)Wordpress 4.2.2 cgi -T1 php opc=on  0.13% -0.19% 
 1.05%
:-)Drupal 7.36 cgi -T1 php opc=on  0.38%  0.05% 
 1.14%
:-|MediaWiki 1.23.9 cgi -T5000 php opc=on  0.22%  0.10% 
 1.00%
:-)  bench.php cgi -T1 php opc=on  0.04%  0.11% 
 4.09%
:-|micro_bench.php cgi -T1 php opc=on  0.04% -0.03% 
 0.03%
:-) mandelbrot.php cgi -T1 php opc=on  0.06% -0.03% 
 4.28%
--
Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in 
fetches/second while all other are measured in seconds.
* Relative Standard Deviation (Standard Deviation/Average)

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

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



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

[PHP-DEV] taint

[Christopher Owen]

Please consider making ‘taint’ a first-class feature/extension in PHP 7.0.

https://pecl.php.net/package/taint 

 Christopher Owen.

[PHP-DEV] Introduction

[Christopher Owen]

Hello PHP Internals.

I would like to introduce myself in order to validate a wiki account for the 
purposes of proposing an RFC.

Thank you for reading this note.

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

RE: [PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP should be configured and built with --enable-huge-code-pages, OS s

[Anatol Belski]

Hi Dmitry,

> -Original Message-
> From: Dmitry Stogov [mailto:dmi...@zend.com]
> Sent: Monday, September 14, 2015 12:58 PM
> To: Anatol Belski ; Kalle Sommer Nielsen ;
> Rasmus Lerdorf ; Xinchen Hui ;
> Nikita Popov ; Zeev Suraski ; Andi
> Gutmans ; PHP Internals 
> Subject: [PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental ability
> to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP should be
> configured and built with --enable-huge-code-pages, OS should be configured to
> provide huge pages. It's possible to
> 
> The effect of this patch is really exiting to keep it disabled by default... 
> :)
> 
> $ perf stat -e instructions,iTLB-loads,iTLB-load-misses,cycles
> sapi/cgi/php-cgi -d opcache.enable_huge_code_pages=0 -T 1
> /var/www/html/bench/wordpress-3.6/index.php > /dev/null
> 
>191,778,620,621  instructions  #0.81  insns per
> cycle
>178,497,016
> iTLB-loads
> 87,351,276  iTLB-load-misses  #   48.94% of all iTLB
> cache hits
>238,136,402,797
> cycles
> 
>  110.221114219 seconds time elapsed
> 
> $ perf stat -e instructions,iTLB-loads,iTLB-load-misses,cycles
> sapi/cgi/php-cgi -d opcache.enable_huge_code_pages=1 -T 1
> /var/www/html/bench/wordpress-3.6/index.php > /dev/null
> 
>191,780,181,536  instructions  #0.83  insns per
> cycle
> 39,017,004
> iTLB-loads
> 41,631,359  iTLB-load-misses  #  106.70% of all iTLB
> cache hits
>231,287,491,307
> cycles
> 
>  107.742837269 seconds time elapsed
> 
> May be we should enable this by default in RC (may be also file cache) and 
> make
> decision based on feedback?
> 
The file cache feature has proven itself as stable already, IMHO it should be 
built by default in RC3.

With the new huge memory pages feature I'd suggest a bit softer - enabling its 
building, but setting opcache.enable_huge_code_pages=0 by default. Then it can 
be easy enable and give one more intermediate step for pre testing and go into 
RC4 completely if ok. What do you think?

Regards

Anatol 


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

Re: [PHP-DEV] taint

[Kalle Sommer Nielsen]

Hi Christopher

2015-09-14 4:44 GMT+02:00 Christopher Owen :
> Please consider making ‘taint’ a first-class feature/extension in PHP 7.0.

It is way too late for any extension to be included in the 7.0 release
now, but you can write an RFC targetting 7.1, please see the wiki for
more details[1].


[1] http://wiki.php.net/rfc



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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