Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

[Michael Wallner]

On Mon, 6 Nov 2023 21:12:40 +0900, Saki Takamachi wrote:

Hi Saki!

> To be honest, I'm completely neutral on this. I believe that this is a
> matter of will and what we want to do. As far as I know, Tim and Gina
> want change on this issue. I don't want to ignore such opinions and move
> forward with implementation, so I would like to hear a wider range of
> opinions.
> 
> I have created this RFC in order to determine "our intention" once
> again.

TBH, the RFC is pretty skinny for such a controversial proposal. I see 
that there are discussions in bug reports and pull requests, but the RFC 
should condense that information, to be useful. Chances are pretty low as 
it stands now.

I didn't look into other languages, like done in another discussion, but I 
looked into some of the most popular RDBMS options, like SQLite, MySQL and 
Postgres, of which all three seem to give 0.29 for your example.

Mike

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

Re: [PHP-DEV] Timezone Rules, which dataset to pick?

[Michael Wallner]

On 07/04/2022 11.34, Derick Rethans wrote:
> Hi!
...
> In the last few years, the maintainer of the Iana TZ Data project has
> diverged somewhat from the consensus of the community, and degraded some
> data by no longer having an entry for each country and merged timezones
> where data does not differ since 1970. (Removing transitions from these
> regions where data **does** differ before 1970, even if these were
> available).
...
> Comments?

This article [1] mentions that tzdata can be built in a way to include 
the "merged away" data:


It is possible to build tzdata with PACKRATDATA=backzone if
historic pre-1970 data is needed.


Would this be an option, too?

[1] 
https://developers.redhat.com/articles/2022/01/28/tzdata-time-zone-database-rhel-2021-update



--
Regards,
Mike


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] Unwrap reference after foreach

[Michael Wallner]

> 
> This seems like a good opportunity to go one step further and have loops 
> create a new scope, which would automagically handle the unwrapping with out 
> worrying about the edge cases. Obviously, this would be a bigger BC break, 
> but one worth considering.
> 

Sounds reasonable, but this is too much a BC break for my taste.
PHP doesn’t have a lot of scopes, and at a quick glance, this would increase 
them by 33%.

I /know/ I wrote code using the last iterated index/key of a loop.

That said, I also /know/ I wrote code using the value-by-reference after the 
loop, so I’m neither keen on voting +1 on the actual proposal. Granted though, 
it’d be an easy fix if there’s already a condition in the loop breaking its 
continuation.

Regards,
Mike




signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [VOTE] Fibers

[Michael Wallner]

Hi Aaron!

Thank you, and everyone involved, for your effort.

On 08/03/2021 20.40, Aaron Piotrowski wrote:
> Greetings everyone!
> 
> The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers 
> 
> 
> Voting will run through March 22nd.

I voted /no/, because of the dependency on Boost.
If my assumptions are wrong, I may reconsider my vote.


-- 
Regards,
Mike



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] Tracking Object Property Changes

[Michael Wallner]

Hi Joseph!

Is this for educational purposes or real world usage?

I ask, because, if you don't have to adhere to a predefined C-API you
would avoid lots of headache by baking all this stuff into your PHP
objects with the APIs provided by Zend. But then again, it would be way
more efficient to just write it all in PHP code.

More comments following inline.

On 09/03/2021 03.32, Joseph Montanez wrote:
> I am not sure what to title this but the gist is that I have two structs
> with a one way dependency:
> 
> // Vector3 type
> typedef struct Vector3 {
> float x;
> float y;
> float z;
> } Vector3;
> 
> // Ray type (useful for raycast)
> typedef struct Ray {
> Vector3 position;   // Ray position (origin)
> Vector3 direction;  // Ray direction
> } Ray;

As these are embedded structs instead of pointers to, neither do point
to the memory of the other.


> The PHP Ray object is defined as so:
> typedef struct _skeleton_ray_object {
> Ray ray;
> HashTable *prop_handler;
> zend_object std;
  
NOTE: This has to be the last line in your object struct because of an
VLA at the end of the zend_object struct. See your xyz_new() function
where you allocate additional zend_object_properties_size() bytes for
that VLA (variable length array).

> 
> skeleton_vector3_object *position;
> skeleton_vector3_object *direction;
> } skeleton_ray_object;
> 
> When I update either vector3 object, I don't have a way to propagate the
> changes back to the parent object(Ray). This means the raw Ray struct is
> never updated. Is there a built-in way to handle propagation (listeners) in
> a PHP extension or will I need to hand roll this?

Yes, you gotta write all of this on your own, but let me repeat that
this is a lot of boilerplate which also may entail lots of headache.


-- 
Regards,
Mike



OpenPGP_signature
Description: OpenPGP digital signature

[PHP-DEV] Re: Array recursion detection in PHP 8

[Michael Wallner]

On 23/09/2020 14:07, Michael Wallner wrote:
> Hi,
> 
> I wondered about PHP 8 detecting recursion earlier than used to and what
> caused that, respectively why it's caused. Compare the following output:
> 
> https://3v4l.org/J7Niu

Could it be that var_dump() was just adjusted to the output of print_r?

https://3v4l.org/QVJS4

Then, sorry for the noise... ;)


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Array recursion detection in PHP 8

[Michael Wallner]

Hi,

I wondered about PHP 8 detecting recursion earlier than used to and what
caused that, respectively why it's caused. Compare the following output:

https://3v4l.org/J7Niu

Thanks in advance for any hints!

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Michael Wallner]

Hi Larry!

Larry Garfield  schrieb am Mi., 24. Juni 2020,
02:30:

> Greetings, Internalians.
>
> *dons flame retardant suit*


Thank your for your efforts, but I'm about to cast a negative vote on this
policy.

Distilled down, I just cannot see any huge benefit out of a (or two) root
namespace(s). As a project we rightfully own the root namespace, and
putting everything beneath PHP just doesn't make any sense to me.

Also, most code more than a handful of files is already vendored, and if
not a common idiom I see often used, is a simple 'app' or ''
namespace.

Closing, just let me ensure that it is not because one of my extensions
accidentally provides a class beneath a 'php' namespace.

Regards,
Mike

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

[Michael Wallner]

Nikita Popov  schrieb am Di., 9. Apr. 2019, 11:54:

> Hi internals,
>
> Inspired by Bob's recent RFC for concat precedence, I'd like to propose a
> deprecation and removal of the left-associative behavior of ternaries.
> Instead, explicit parentheses should be used:
>
> https://wiki.php.net/rfc/ternary_associativity
>
> This RFC makes nested ternaries without disambiguating parentheses an error
> in PHP 8 -- we might want to consider making them right-associative
> instead, which is both useful and matches the behavior of other languages.
>
> Regards,
> Nikita
>

Simple, +1.

Regards,
Mike

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Michael Wallner]

On 03/04/2019 12:27, Diogo Neves wrote:
> It really don't make much sense:
> 
>  
> var_dump( PHP_FLOAT_MIN < 0 );
> var_dump( PHP_INT_MIN < 0 );
> 
> On Wed, Apr 3, 2019 at 10:52 AM Benjamin Morel 
> wrote:
> 
>> Hi internals,
>>
>> I just used PHP_FLOAT_MIN for the first time, and was surprised that it is
>> the smallest **positive** number representable. Is this expected?
>>
>> This is unlike PHP_INT_MIN, which is the absolute smallest representable
>> integer, and as such is negative:
>>
>> echo PHP_INT_MIN; // -9223372036854775808
>> echo PHP_FLOAT_MIN; // 2.2250738585072E-308
>>
>> If it is intended, maybe the doc
>>  should be clear
>> about this, at the moment it is just:
>>
>> Smallest representable floating point number.
>>
>>
>> Which is confusing IMO.

FLT_MIN is the smallest real near 0. Are you looking for -FLT_MAX?
With IEEE754 floats, there are positive and negative zeros, so the range
above and below 0 is the same.


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

[Michael Wallner]

On 25/03/2019 16:38, Andrey Andreev wrote:

> 
> OK, so why not flip it and make it always available instead? I'm aware
> of the potential XML conflict, but I've personally never seen it, so
> to me that looks like the lesser evil compared to a massive BC break.


I slightly lean towards removing support for '

signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP on OSS-fuzz

[Michael Wallner]

Hey!

On 17/03/2019 22:23, Stanislav Malyshev wrote:
> Hi!
> 
> Looking at the recent PHP security issues, it is clear that many of them
> are stemming from corner cases in various format-parsing code, and most
> of them either is or can be found by fuzzers.
> 
> Thus, I've made an initial integration for PHP on OSS-fuzz project - a
> fuzzing engine for testing open source projects. PHP configuration sits
> here:
> https://github.com/google/oss-fuzz/tree/master/projects/php

I followed the progress on github. Thanks for doing the work up front.

> and implementation of fuzzers is here:
> https://github.com/php/php-fuzzing-sapi
> 
> So far we have three fuzzers enabled: JSON, EXIF and mbstring. I plan
> also to add basic phar fuzzer soon. Everybody is welcome to add more
> fuzzers - with priority on ones that actually deal with third-party
> data, e.g. language parser fuzzer is not enabled right now, because
> people usually do not run random byte streams as PHP scripts on their
> servers. On the other hand, people do apply EXIF or gd functions to
> third-party data, so a vulnerability in that code would be high priority.
> 
> That said, fuzzers can be run independently of OSS-Fuzz, so if you feel
> inspired to add a fuzzer for any code please do so.
> 

I hope I'll find time to try it out soon, thanks again!


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Proposal for deprecate alternate syntax(curly braces) for array and string access

[Michael Wallner]

On 15/03/2019 14:39, Andrey O Gromov wrote:
> Reasons to deprecate curly braces syntax::
> 1.  Two ways to do the same thing.
> 2.  It is very rarely used nowadays.
> 3.  It is almost not documented. There is only two short “NOTE” about 
> it.
> 4.  Also, this syntax has reduced functionality. You can't use it for 
> pushing element into array “$arr{} = 1;”, creating array “$a={1,2};” or in 
> other similar cases.
> 5.  Deprecation and following removal will free this syntax for other 
> features. For example: array/string slice, absolute offset access, 
> “windows” (like “slice” in GoLang), etc.
> 
> Proposal
> https://wiki.php.net/rfc/deprecate_curly_braces_array_access


Do I understand it right, that you're proposing deprecating accessing
$string{$offset}? I think that's an important way of differentiation
between string and array offset access.

I'd vote "yes" for splitting syntax on array and string offset access,
but as is: -1.

> 
> Patch diff
> https://github.com/php/php-src/compare/PHP-7.4...rjhdby:deprecate_alternate_array_access
> 
> Migration script
> https://github.com/rjhdby/php-src/blob/deprecate_alternate_array_access/convert_array_access_braces.php
> 


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [Proposal] Struct Data Types

[Michael Wallner]

On 15/03/2019 04:49, Kenneth Ellis McCall wrote:
> Hey all,
> 
> I'm looking to get feedback on a RFC I want to propose.
> 
> PHP RFC: Addition of the 'struct' data type.
> 
> Introduction:
> PHP has many data types, but does not offer something that is the
> equivalent to the C struct data type.
> 
> The purpose of this RFC is to propose a data type of 'struct', which
> would be a strictly typed, immutable data structure that resembles a mix
> of a class and an array.

Would this type be a COW or pass-by-ref type?
Because.. I guess that could make all the difference...
If it's gonna be pass-by-ref, and I assume so, because you explicitly
mentioned immutable, then it's just a class minus behaviour?
That would probably simplify internals a lot, I guess?


> 
> Pros:
> Provides a data type which would immutable and self-validating by
> mandatory type hinting.
> 
> Cons:
> ?
> 
> Possible future considerations:
> Advanced Type Validators.
> 
> Use cases:
> Configurations, DTOs, anything that needs a strict schema.
> 
> Proposed usage / syntax:
> struct MyStuct
> {
>     boolean|bool  'prop01';
>     integer|int   'prop02';
>     double    'prop03';
>     string    'prop04';
>     array 'prop05';
>     object    'prop06';
>     resource  'prop07';
>     callable  'prop08';
>     iterable  'prop09';
>     Acme\MyClass  'prop10';
>     Acme\ConfStruct   'prop11';
>     array Acme\AnotherStruct  'prop12';
>     ?boolean|bool 'prop13';
>     ?integer|int  'prop14';
>     ?double   'prop15';
>     ?string   'prop16';
>     ?array    'prop17';
>     ?object   'prop18';
>     ?resource 'prop19';
>     ?callable 'prop20';
>     ?iterable 'prop21';
>     ?Acme\MyClass 'prop22';
>     ?Acme\ConfStruct  'prop23';
>     ?array Acme\AnotherStruct 'prop24';
> }
> OR?
> 
> struct MyStuct
> {
>     'prop01': boolean|bool;
>     'prop02': integer|int;
>     'prop03': float;
>     'prop04': string;
>     'prop05': array;
>     'prop06': object;
>     'prop07': resource;
>     'prop08': callable;
>     'prop09': iterable;
>     'prop10': Acme\MyClass;
>     'prop11': Acme\ConfStruct;
>     'prop12': array Acme\AnotherStruct;
>     'prop13': ?boolean|bool;
>     'prop14': ?integer|int;
>     'prop15': ?float;
>     'prop16': ?string;
>     'prop17': ?array;
>     'prop18': ?object;
>     'prop19': ?resource;
>     'prop20': ?callable;
>     'prop21': ?iterable;
>     'prop22': ?Acme\MyClass;
>     'prop23': ?Acme\ConfStruct;
>     'prop24': ?array Acme\AnotherStruct;
> }
> 
> struct Acme\ConfStruct
> {
>     string 'host';
>     ?int 'port';
> }
> 
> struct Acme\AnotherStruct
> {
>     string 'firstName';
>     string 'lastName';
>     ?integer 'age';
> }
> 
> Acme\ConfStruct $a = {
>     'host' => '127.0.0.1',
>     'port' => 8088
> }
> 
> Acme\MyStruct $myStruct = {
>     'prop01' => true,
>     'prop02' => 1,
>     'prop03' => 1.01,
>     'prop04' => 'Hello',
>     'prop05' => ['a', 'b', 'c'],
>     'prop06' => new stdClass(),
>     'prop07' => fopen('xyz.txt', 'wb'),
>     'prop08' => function() {
>     return 1 + 1;
>   },
>     'prop09' => [
>     [1, 2, 3],
>     [4, 5, 6],
>     [7, 8, 9]
>     ],
>     'prop10' => new Acme\MyClass,
>     'prop11' => $a,
>     'prop12' => [
>     Acme\AnotherStruct [
>     'firstName' => 'Bob',
>     'lastName'  => 'Walker'
>     ],
>     Acme\AnotherStruct [
>     'firstName' => 'Little',
>     'lastName'  => 'Johnny',
>     'age'   => 5
>     ],
>     ],
>     'prop13' => null,
>     'prop14' => null,
>     'prop15' => null,
>     'prop16' => null,
>     'prop17' => null,
>     'prop18' => null,
>     'prop19' => null,
>     'prop20' => null,
>     'prop21' => null,
>     'prop22' => null,
>     'prop23' => null,
>     'prop24' => null
> };
> 
> $x = new Some\Other\Class($myStruct);
> 
> echo $myStruct['prop02'];
> OR?
> 
> echo $myStruct->prop02;
> Warning / Errors / Exceptions:
> Acme\MyStruct $a = {
>     'prop01' => 5,
>     ...
> }
> // Should: throw new TypeError("'prop01' should be set as a boolean
> type, integer type was attempted.")
> 
> echo $a['xyz']; // or echo $a->xyz (which ever is the preferred syntax
> after comments).
> // Should: trigger_error("Notice: Undefined property:
> Acme\MyStruct::xyz");
> 
> 
> https://github.com/ellisgl/PHP-RFC-Struct-Data-Type
> 

I'd prefer a syntax more resembling the current syntax for declaring
classes:

struct Config {
bool $enabled = true;
?string $path = null;
}

The draft does not specify what features of classes/arrays will remain
after "mixing" it to a struct type.


-- 
Regards,
Mike



signature.asc
Descripti

Re: [PHP-DEV][RFC] Allow void return type variance

[Michael Wallner]

I second Rowans thoughts.

Am So., 17. Feb. 2019, 17:36 hat Rowan Collins 
geschrieben:

> On 04/02/2019 03:22, Wes wrote:
> > Recent events convinced me to write this RFC :P
> >
> > Please have a read here https://wiki.php.net/rfc/allow-void-variance
>
>
> I was thinking about this this afternoon, and I think the current
> behaviour is actually correct, and this constraint should stay invariant.
>
> My reasoning is that ": void" isn't actually a *type constraint* - there
> is no "void type" to apply the rules of covariance and contravariance
> to. It's tempting to place it on a par with ": null", but a void
> function evaluates to null only for the same reason an unset variable
> does: because the runtime has to give you *something*.
>
> Instead, ": void" in PHP represents a *behavioural constraint* on the
> function - it declares that within this function, anything of the form
> "return $value" is to be treated as an error. In other languages, the
> same constraint might be enforced by declaring the routine as a
> "procedure" rather than a "function".
>
> As such, it is more appropriate to compare "void vs non-void" to "static
> vs non-static", which is an invariant constraint - you can't over-ride a
> static method with a non-static one, or vice versa.
>
>
> (Incidentally, the RFC mentions TypeScript as precedent; there, "void"
> apparently *is* a type, not just a keyword in function signatures:
> https://www.typescriptlang.org/docs/handbook/basic-types.html)
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] New website for the PHP project

[Michael Wallner]

Am Do., 7. Feb. 2019, 10:27 hat BohwaZ/PHP  geschrieben:

> Le 04/02/2019 01:14, azjezz a écrit :
> > In my opinion, current design looks old, outdated and bland. This
> > sadly may reflect "badly" on the language reputation nowadays.
>
> I find that the main PHP website is quite good actually, the design
> looks modern, it is quite clear and easy to use and it provides great
> access to documentation.
>


Yeah, I think so, too. Thank you Levi et al!


> I have to say the PHP documentation is usually great (and when it's not,
> just change it :) ), and the feature where you can just type
> php.net/function to get direct access  to the documentation of a
> function/feature is great, although it doesn't search in methods, eg.
> http://php.net/setParam will not return anything about PDOStmt::setParam
>


Could not find anything about PDOStmt::setParam either, but I fixed it for
you: http://php.net/pdostatement_bindparam
You're welcome ;)


I also love the comments feature, people often provide great examples,
> tips or replacement functions for old PHP versions, this is very
> helpful!
>
> So I don't think that we need to redesign and start over, but iterate
> and make the current website better, please don't throw out what is
> already good :) It would be a recipe for disaster.
>
> But I have to agree that signing to the internals list wasn't an easy
> task as the website form wasn't working when I subscribed 2 years ago,
> but it might have been fixed?
>
> > # FrontEnd Framework
> >
> > We don't need that too, but we can use one ! there's some light-weight
> > options out there.
>
> Please only use HTML and CSS, don't use a JS framework. The website
> should be future-proof and not broken and hard to maintain in 6 months.
> Also it should be lightweight and not download a bunch of code just to
> display stuff. HTML and CSS are more than plenty for our needs :)
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: RFC Weakrefs

[Michael Wallner]

On 03/02/2019 22:49, Christoph M. Becker wrote:

> 
> Not sure about removal from the PHP manual.  This may never have
> happened before (except for PECL/idn which conflicted with ext/intl).
> Might be better to discuss this on the doc mailing list.
> 
> F'up2 
> 

Oh, it happened. I deleted http-v1 docs a few years ago.

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] FPM maintainership?

[Michael Wallner]

Hi!

How to get this going forward?

On 21/02/2018 10:45, Michael Wallner wrote:
> On 21/02/18 10:29, Remi Collet wrote:
>> Hi,
>>
>> Le 21/02/2018 à 10:21, Michael Wallner a écrit :
>>> I also have a patch I'd like to discuss with the new maintainers, which
>>> attempts to fix FPM's SIGUSR2 graceful restart behaviour, and which
>>> we've been running for half a year now IIRC.
>>
>> Any link to the patch ?
> 
> Sure, attached!
> 


-- 
Regards,
Mike
commit 08754dba5a87128bd7182bb2146ff64036fecaa1
Author: Michael Wallner 
Date:   Wed Mar 15 08:43:04 2017 +0100

php-fpm: graceful restart without losing requests

diff --git a/sapi/fpm/fpm/fpm_process_ctl.c b/sapi/fpm/fpm/fpm_process_ctl.c
index ca5a6f2e40..72985699aa 100644
--- a/sapi/fpm/fpm/fpm_process_ctl.c
+++ b/sapi/fpm/fpm/fpm_process_ctl.c
@@ -80,6 +80,16 @@ static void fpm_pctl_exit() /* {{{ */
 static void fpm_pctl_exec() /* {{{ */
 {
 
+	switch (fork()) {
+	case 0:
+		break;
+	case -1:
+		zlog(ZLOG_SYSERROR, "failed to reload: fork() failed");
+		/* no break */
+	default:
+		fpm_global_config.pid_file = NULL;
+		return;
+	}
 	zlog(ZLOG_NOTICE, "reloading: execvp(\"%s\", {\"%s\""
 			"%s%s%s" "%s%s%s" "%s%s%s" "%s%s%s" "%s%s%s"
 			"%s%s%s" "%s%s%s" "%s%s%s" "%s%s%s" "%s%s%s"
@@ -108,9 +118,8 @@ static void fpm_pctl_action_last() /* {{{ */
 {
 	switch (fpm_state) {
 		case FPM_PCTL_STATE_RELOADING:
-			fpm_pctl_exec();
-			break;
-
+			zlog(ZLOG_NOTICE, "exiting after reload");
+			exit(FPM_EXIT_OK);
 		case FPM_PCTL_STATE_FINISHING:
 		case FPM_PCTL_STATE_TERMINATING:
 			fpm_pctl_exit();
@@ -197,6 +206,10 @@ static void fpm_pctl_action_next() /* {{{ */
 	fpm_pctl_kill_all(sig);
 	fpm_signal_sent = sig;
 	fpm_pctl_timeout_set(timeout);
+
+	if (fpm_signal_sent == SIGQUIT && fpm_state == FPM_PCTL_STATE_RELOADING) {
+		fpm_pctl_exec();
+	}
 }
 /* }}} */
 
diff --git a/sapi/fpm/fpm/fpm_sockets.c b/sapi/fpm/fpm/fpm_sockets.c
index d58a8f82b6..5016914395 100644
--- a/sapi/fpm/fpm/fpm_sockets.c
+++ b/sapi/fpm/fpm/fpm_sockets.c
@@ -60,7 +60,17 @@ static void fpm_sockets_cleanup(int which, void *arg) /* {{{ */
 
 		if (which == FPM_CLEANUP_PARENT_EXIT_MAIN) {
 			if (ls->type == FPM_AF_UNIX) {
-unlink(ls->key);
+struct sockaddr_un sa_un;
+
+memset(&sa_un, 0, sizeof(sa_un));
+strlcpy(sa_un.sun_path, ls->key, sizeof(sa_un.sun_path));
+sa_un.sun_family = AF_UNIX;
+
+if (fpm_socket_unix_test_connect(&sa_un, sizeof(sa_un)) == 0) {
+	zlog(ZLOG_WARNING, "Keeping unix socket, another FPM instance seems to already listen on %s", ls->key);
+} else {
+	unlink(ls->key);
+}
 			}
 		}
 		free(ls->key);


signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

[Michael Wallner]

Am Do., 20. Dez. 2018, 16:13 hat Dmitry Stogov 
geschrieben:

> Hi internals,
>
>
> The FFI RFC is turned into voting state.
>
>
> https://wiki.php.net/rfc/ffi
> ...


As the other one, lagging hugely behind, I'll refrain my vote.

Regards,
Mike

Re: [PHP-DEV] [RFC] Preloading

[Michael Wallner]

On 20/10/2018 15:06, Dmitry Stogov wrote:
> 
> 
> On Oct 19, 2018 5:20 PM, Sara Golemon  wrote:
> On Fri, Oct 19, 2018 at 3:17 AM Dmitry Stogov  wrote:
>> I would like to start discussion on a Preloadng RFC 
>> https://wiki.php.net/rfc/preload
>>

> 4) "In conjunction with ext/FFI (dangerous extension), we may allow
> FFI functionality only in preloaded PHP files, but not in regular
> ones."  Is there any interest in something like HHVM's HNI interface?
> FFI always sounds nice in theory, but complex types mean that a little
> bit of glue code is often a plus.


As always when it comes to PHP and FFI I'd like to point out ext-psi [1]
which uses a different approach than other PHP FFIs until now.

It parses PSI files at startup, which basically are C header files
augmented with the PHP userland interface decls, see for example the PSI
file for time.h [2]

As you can see, marshalling from and to native types has been taken
seriously, and while we're capable of recursively unmarshalling e.g.
addrinfo structs [3] and handling sqlite callbacks [4] it's still not
possible yet for something like curl_easy_setopt.



[1] https://github.com/m6w6/ext-psi
[2] https://github.com/m6w6/ext-psi/blob/master/psi.d/time.psi
[3] https://github.com/m6w6/ext-psi/blob/master/psi.d/netdb.psi#L70
[3] https://github.com/m6w6/ext-psi/blob/master/tests/netdb/gai001.phpt
[4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite.psi#L56
[4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite001.phpt


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP FFI extenesion

[Michael Wallner]

> On 26 04 2018, at 11:25, Dmitry Stogov  wrote:
> 
> 
> Did you use PSI with some complex libraries?

Define complex. There’s a working sqlite test (quite simple use case for 
sqlite, though):
https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite001.phpt 


Thanks,
Mike

Re: [PHP-DEV] PHP FFI extenesion

[Michael Wallner]

Hey!

> On 26 04 2018, at 20:47, Dmitry Stogov  wrote:
> 
> Hi Michael,
> 
> 
> I've just tried to run PSI with php-master (32-bit DEBUG build) and got 
> SIGSEGV on the simplest test.
> 
> Use "psi.d/string.psi" and attemt to call psi\strerror(10)
> 
> 
> #0  0xf44916ba in psi_call_frame_parse_args (frame=0xf426c500, 
> execute_data=0x0) at /home/dmitry/php/ext-psi/src/call.c:273
> #1  0xf4494fe7 in psi_context_call (C=0x92dfe90, execute_data=0x0, 
> return_value=0x8fc0144 , impl=0x9341658)
>at /home/dmitry/php/ext-psi/src/context.c:250
> #2  0xf4499b44 in psi_ffi_handler (sig=0x92e0fa0, result=0x9760, 
> args=0x96f0, data=0x9341658)
>at /home/dmitry/php/ext-psi/src/libffi.c:387
> #3  0xf4467a76 in ffi_closure_SYSV_inner () from /lib/libffi.so.6
> #4  0xf4467eb6 in ffi_closure_SYSV () from /lib/libffi.so.6
> #5  0x08701d21 in ZEND_DO_FCALL_BY_NAME_SPEC_RETVAL_USED_HANDLER () at 
> /home/dmitry/php/php-master/Zend/zend_vm_execute.h:890
> #6  0x0875fd12 in execute_ex (ex=0xf421d020) at 
> /home/dmitry/php/php-master/Zend/zend_vm_execute.h:54819
> #7  0x087643b1 in zend_execute (op_array=0xf426c460, return_value=0x0) at 
> /home/dmitry/php/php-master/Zend/zend_vm_execute.h:59987
> #8  0x086b0d2f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
> /home/dmitry/php/php-master/Zend/zend.c:1566
> #9  0x0863cdde in php_execute_script (primary_file=0xcbbc) at 
> /home/dmitry/php/php-master/main/main.c:2467
> #10 0x0876676a in do_cli (argc=2, argv=0x90e4850) at 
> /home/dmitry/php/php-master/sapi/cli/php_cli.c:1011
> #11 0x087673b2 in main (argc=2, argv=0x90e4850) at 
> /home/dmitry/php/php-master/sapi/cli/php_cli.c:1404
> 
> execute_data is NULL
> 
> 
> Did you test ext-psi with php-master?
> 

I only test on master, but never tested 32bit :-/
https://travis-ci.org/m6w6/ext-psi/jobs/368760446#L2102

> 
> As I understood, you create libffi callback/closure for each function 
> declared in *.psi file(s).
> 
> And then use it to call a general psi_ffi_handler().
> 
> Why not to call a general function handler in first place (without any ffi 
> magic)?
> 

Let me think about that. It’s my first with libffi/libjit, so maybe I was 
thinking too complicated and took more corners than I had to…

Thanks,
Mike


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

Re: [PHP-DEV] PHP FFI extenesion

[Michael Wallner]

Hey Dmitry!

On 17/04/18 09:29, Dmitry Stogov wrote:
> hi Michael,
> 
> it's pitty, I didn't found this extension before.
> thanks for pointing, I'll definetly take a look.

Did you have a chance to look at it yet?


> I, also, like the idea of preloading ffi definitions on startup, but I
> would prefer to allow preloading any php files. Especially for FFI, PHP
> wrappers would able to hide dangerous implementation details.
> 

I'm not sure the one depends on the other, and how would that be
different to opcache?

With PSI everything related C is encapsulated, you cannot change
anything regarding the access or calling scheme at runtime.

I admit, PSI is far away from being optimized or even finished yet, but
there are a few important key differentiation points:

- the system administrator controls FFI
- parses C headers, no need to duplicate declarations
- function call and data access is pre-defined, not at runtime

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP FFI extenesion

[Michael Wallner]

Hi!

Nice that FFI is of interest again, so may I kindly point you to ext-psi?
https://github.com/m6w6/ext-psi


It follows a different approach, though, that it requires definition
files on startup, not at runtime.

Basically:

$ cat >time.psi <
/* time_t time(time_t *tloc); man 2 time */
function psi\time() : int {
let tloc = NULL;
return time(tloc) as to_int(time);
}
EOF


$ ./sapi/cli/php -d psi.directory=. -r 'var_dump(psi\time());'

It stalled the last months because I have been fighting health issues
since last summer, but I did post a link to internals about a year ago:
https://externals.io/message/98212#98259

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] FPM maintainership?

[Michael Wallner]

On 21/02/18 10:29, Remi Collet wrote:
> Hi,
> 
> Le 21/02/2018 à 10:21, Michael Wallner a écrit :
>> I also have a patch I'd like to discuss with the new maintainers, which
>> attempts to fix FPM's SIGUSR2 graceful restart behaviour, and which
>> we've been running for half a year now IIRC.
> 
> Any link to the patch ?

Sure, attached!

-- 
Regards,
Mike
commit 08754dba5a87128bd7182bb2146ff64036fecaa1
Author: Michael Wallner 
Date:   Wed Mar 15 08:43:04 2017 +0100

php-fpm: graceful restart without losing requests

diff --git a/sapi/fpm/fpm/fpm_process_ctl.c b/sapi/fpm/fpm/fpm_process_ctl.c
index ca5a6f2e40..72985699aa 100644
--- a/sapi/fpm/fpm/fpm_process_ctl.c
+++ b/sapi/fpm/fpm/fpm_process_ctl.c
@@ -80,6 +80,16 @@ static void fpm_pctl_exit() /* {{{ */
 static void fpm_pctl_exec() /* {{{ */
 {
 
+	switch (fork()) {
+	case 0:
+		break;
+	case -1:
+		zlog(ZLOG_SYSERROR, "failed to reload: fork() failed");
+		/* no break */
+	default:
+		fpm_global_config.pid_file = NULL;
+		return;
+	}
 	zlog(ZLOG_NOTICE, "reloading: execvp(\"%s\", {\"%s\""
 			"%s%s%s" "%s%s%s" "%s%s%s" "%s%s%s" "%s%s%s"
 			"%s%s%s" "%s%s%s" "%s%s%s" "%s%s%s" "%s%s%s"
@@ -108,9 +118,8 @@ static void fpm_pctl_action_last() /* {{{ */
 {
 	switch (fpm_state) {
 		case FPM_PCTL_STATE_RELOADING:
-			fpm_pctl_exec();
-			break;
-
+			zlog(ZLOG_NOTICE, "exiting after reload");
+			exit(FPM_EXIT_OK);
 		case FPM_PCTL_STATE_FINISHING:
 		case FPM_PCTL_STATE_TERMINATING:
 			fpm_pctl_exit();
@@ -197,6 +206,10 @@ static void fpm_pctl_action_next() /* {{{ */
 	fpm_pctl_kill_all(sig);
 	fpm_signal_sent = sig;
 	fpm_pctl_timeout_set(timeout);
+
+	if (fpm_signal_sent == SIGQUIT && fpm_state == FPM_PCTL_STATE_RELOADING) {
+		fpm_pctl_exec();
+	}
 }
 /* }}} */
 
diff --git a/sapi/fpm/fpm/fpm_sockets.c b/sapi/fpm/fpm/fpm_sockets.c
index d58a8f82b6..5016914395 100644
--- a/sapi/fpm/fpm/fpm_sockets.c
+++ b/sapi/fpm/fpm/fpm_sockets.c
@@ -60,7 +60,17 @@ static void fpm_sockets_cleanup(int which, void *arg) /* {{{ */
 
 		if (which == FPM_CLEANUP_PARENT_EXIT_MAIN) {
 			if (ls->type == FPM_AF_UNIX) {
-unlink(ls->key);
+struct sockaddr_un sa_un;
+
+memset(&sa_un, 0, sizeof(sa_un));
+strlcpy(sa_un.sun_path, ls->key, sizeof(sa_un.sun_path));
+sa_un.sun_family = AF_UNIX;
+
+if (fpm_socket_unix_test_connect(&sa_un, sizeof(sa_un)) == 0) {
+	zlog(ZLOG_WARNING, "Keeping unix socket, another FPM instance seems to already listen on %s", ls->key);
+} else {
+	unlink(ls->key);
+}
 			}
 		}
 		free(ls->key);


signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] FPM maintainership?

[Michael Wallner]

On 21/02/18 01:42, Stanislav Malyshev wrote:
> Hi!
> 
> I'd like to raise the question of FPM SAPI maintainership. Is it still
> maintained? If so, by whom? Jerome Loyet is listed as a maintainer, but
> his last commit has been in 2012, as far as I can see, and I see no
> activity from him on the bug tracker for the last couple of years (maybe
> more). FPM is a pretty important module and widely used, and we have
> over 100 bugs in the bug DB for it, not being addressed. Would anyone
> like to step up for his module? If not, what's the plan for keeping it
> alive and well?

I'd like to second that. Given the past development of heading away from
SAPIs loaded into the webserver to FastCGI being preferred, we should be
giving FPM the deserved priority. Does anyone have stats about the
popularity of our SAPIs?

I also have a patch I'd like to discuss with the new maintainers, which
attempts to fix FPM's SIGUSR2 graceful restart behaviour, and which
we've been running for half a year now IIRC.

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Parallelised run-tests.php (patch)

[Michael Wallner]

Hi!

On 08/10/17 05:47, Andrea Faulds wrote:> Hi there,
>
> Do you spend HOURS every day AGONISING over how long run-tests.php takes
> to complete?
Yes!

>
> Have you long since ABANDONED every test directory besides Zend/tests?
>
> Does it feel like your eight CPU cores are pointlessly WASTED by
> single-threaded PHP test execution?
Yes!

>
> Are you SADDENED every day at how high-quality the run-tests.php code
> is, DREAMING of an even worse mess?
>
> Then I've got just the trick for you!
Ha, welcome to the club! I'm glad someone else feels the need, too.
https://github.com/php/php-src/compare/master...m6w6:parallel-run-tests

But, I just noticed, you've been part of that discussion, too:
https://externals.io/message/75308

-- 
Regards,
Mike





signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Re: [PHP-CVS] com php-src: fix default args for --with-pcre-valgrind: ext/pcre/config0.m4

[Michael Wallner]

On 25/07/17 00:31, Christopher Jones wrote:
> 
> 
> On 20/7/17 10:31 am, Anatol Belski wrote:
>> Hi Chris,
>>
>>> -Original Message-
>>> From: Christopher Jones [mailto:christopher.jo...@oracle.com]
>>> Sent: Thursday, July 20, 2017 2:11 AM
>>> To: Anatol Belski ; php-...@lists.php.net; Tianfang Yang
>>> 
>>> Subject: Re: [PHP-CVS] com php-src: fix default args for
>>> --with-pcre-valgrind:
>>> ext/pcre/config0.m4
>>>
>>> Hi Anatol,
>>>
>>> 7.2 & 7.3 builds now fails for me on macOS and Oracle Linux 7 with:
>>>
>>>     checking for Valgrind headers location... configure: error: Could
>>> not find
>>> valgrind/memcheck.h
>>>     Configure failed
>>>
>>> Do we really want users to have to explicitly disable PCRE valgrind
>>> when they are
>>> using --enable-debug?
>>>
>> It wasn't by default in the first version, later it was suggested by
>> Nikita and for debug mode certainly makes sense, as for me. The reason
>> behind this option is the upgrade of the bundled PCRE, which shows a
>> lot of false positives without the integrated Valgrind support. Also I
>> was basing on the fact the debug mode is actually developers only,
>> normal use wouldn't be affected therefore. Why would users do debug
>> builds?
>>
>> On a dev machine Valgrind would be anyway present. For developers it's
>> best to have it by default, as PCRE usage is spread around the core
>> here and there. Bug fixing also does normally involve valgrind checks.
>> I wouldn't see the option itself as a big question, either way. If
>> many people find the default enablement unsuitable, so the behavior
>> can be reversed.
>>
>> Regards
>>
>> Anatol
>>
> I'm not totally convinced merging debug-level arguments makes sense (why
> not always enable --enable-phpdbg-debug too?)  But there are more
> important things to worry about, so I won't stress.
> 
> BTW, './configure --help' prints the --with-pcre-valgrind=DIR help twice.
> 
> Chris
> 

Just stumbled over this one, too.

I don't think it's very nice to suddenly let ./configure --enable-debug
die when valgrind headders are not present, and I didn't request
valgrind support in ext/pcre.


Suddenly all of my travis builds failed, for no apparent reason, despite
--disable-all

I think it should only fail hard, if explicitly requested.


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [Request for Comment] Loading dynamic libraries with cross dependencies.

[Michael Wallner]

On 28/02/17 20:13, Sara Golemon wrote:
> The average PHP extension is dependent only on the PHP runtime it was
> built for and probably one or more 3rd party libraries.  However, a
> special class of extensions (such as PDO drivers and much of the XML
> family) have dependencies on other PHP extensions which may (or may
> not) be preset at the time they are loaded in via ini settings and/or
> dl().
> 
> This situation was partially addressed by Wez back in PHP 5.2 with the
> addition of zend_module_dep in the module entry header.  Combined with
> RTLD_LAZY during DL_LOAD() (a portability macro for dlopen()), this
> allows modules to be inspected for dependencies and conflicts prior to
> being registered with the runtime.

I, for a long time, thought that the module deps facility was broken,
until I discovered, that it was just not working for me, because I used
a function pointer:
https://github.com/m6w6/ext-http/commit/7493ad081ec06081cb8ca0f804d98a263f93ffbc

> 
> Unfortunately RTLD_LAZY has some limitations.  From `man dlopen`:
> """Lazy binding is performed only for function references; references
> to variables are always immediately bound when the shared object is
> loaded."""  Given PHP's heavy use of XG() macros to access "globals",
> the odds of a missing symbol during module load is therefore fairly
> high resulting in an inability to inspect zend_module_dep structures
> and provide a meaningful error message to end users.

In my book, using XG() should be avoided and must not be used outside of
the owning module. If really needed, there should be an appropriate
public API. IMO.


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [Discussion] FFI in PHP

[Michael Wallner]

On 08/02/17 14:54, Michał Brzuchalski wrote:
> 2017-02-08 12:51 GMT+01:00 Michael Wallner :
> 
>>
>> ```
>> // https://github.com/m6w6/ext-psi#implementations
>> function math\add(int $a, int $b) : int {
>> let a = intval($a);
>> let b = intval($b);
>> return to_int(add);
>> }
>> ```
>>
> 
> What is the purpose of `intval` call if both variables were declared as int
> already?
> Also what to_int stands for if we already declared int return type?
> 

While those type casts might seem superfluous for simple functions,
marshalling between PHP and C quickly becomes complicated and requiring
explicit casts just reduces the possibility of tripping points even if
the types match on both sides. Omitting them wouldn't change anything
internally, but just bloat the parser.

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [Discussion] FFI in PHP

[Michael Wallner]

On 05/02/17 23:25, Alex Bowers wrote:
> And here is the previous messaging without borked formatting. Sorry folks.
> 
> 
> FFI RFC
> ==
...
> Example
> ===
> 
> Take an example of a rust program that takes two numbers in and gives
> you the sum of them.
> 
> ```rust
> #[no_mangle]
> pub extern fn add(a: i32, b: i32) -> i32 {
> a + b
> }
> 
> ```
> 
> with the Cargo.toml file containing:
> 
> ```
> [package]
> name = "math"
> version = "0.1.0"
> authors = ["Alex Bowers "]
> 
> [dependencies]
> 
> [lib]
> name = "math"
> crate-type = ["dylib"]
> ```
> 
> `cargo build --release` will create `.so`, `.dylib`, or `.dll` files
> depending on your system.
> 
> These should be usable within PHP using the exposed functions.
> 
> ```php
> $math = ffi("/path/to/math.so");
> $result = $math->add(1, 5);
> 
> echo $result; // 6
> ```

With ext/psi [1], that would work differently. You wouldn't define the
interface at runtime, like the above example, pecl/ffi [2] or MFFI [3].

First, you would create an interface description file (a PSI file [4]),
where you specify the native declaration and the library to load:

```
// https://github.com/m6w6/ext-psi#lib
lib "/path/to/math.so";

// https://github.com/m6w6/ext-psi#declarations
extern int32_t add(int32_t a, int32_t b);
```

The PHP interface to this function would usually be defined in the same
file possibly looking along the following lines:

```
// https://github.com/m6w6/ext-psi#implementations
function math\add(int $a, int $b) : int {
let a = intval($a);
let b = intval($b);
return to_int(add);
}
```

Those PSI files would be loaded from a directory configured in php.ini
(psi.directory) and loaded at startup, i.e. the interfaces would be
available to user land for the lifetime of the process, not the request.

Have a look at the complete libidn example [5] of the README or the
sqlite test [6] utilizing a user land callback.

I've been working on ext/psi for the good parts of more than a year now,
and I would be more than happy about insights, suggestions or
collaboration with other interested parties.

The (currently) two major to-dos are decent CPP support in the parser,
so one could basically just parse C headers, and levelling out support
for input/output marshalling, which currently differ in sophistication,
AFAIR, while quite a lot is already possible. Other random bits can be
found in the TODO [7].

It has been successfully built and run on Linux and OSX but YMMV; also,
grab a coffee when building the first time, because `configure` performs
a ton of checks for POSIX builtins (still like, 10% only yet), so don't
forget the -C/--cache-file switch.


[1] https://github.com/m6w6/ext-psi
[2] https://pecl.php.net/ffi
[3] https://github.com/mgdm/MFFI
[4] https://github.com/m6w6/ext-psi#psi-files
[5] https://github.com/m6w6/ext-psi#complete-example
[6] https://github.com/m6w6/ext-psi/tree/master/tests/sqlite
[7] https://github.com/m6w6/ext-psi/blob/master/TODO

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [Discussion] FFI in PHP

[Michael Wallner]

On 05/02/17 23:25, Alex Bowers wrote:
> And here is the previous messaging without borked formatting. Sorry folks.
> 
> 
> FFI RFC
> ==
> 
> There are many languages that support an FFI implementation.
> 
> NodeJS
> Python
> C++
> Ruby
> 
> FFI allows you to call a native C function without requiring the
> boilerplate of an extension to be written.
> 
> There are several benefits to having FFI
> 
> - Performance
> - Shareability / Bundling
> - Common functionality between languages
> 
> Performance
> ===
> Although less pronounced than the 5.x versions, there is still a
> performance benefit to having native C code over PHP code. For
> example, you could utilise threading inside of your FFI methods, which
> PHP does not expose the ability to do.
> 
> Shareability
> ===
> 
> If you wish to implement some of your source code in C, the current
> way to share it is to build it as an extension. This is cumbersome,
> and restricts use-cases such as shared hosting, where the ability to
> install your own extensions is probably restricted. However, with FFI,
> the shared object can be loaded from any location, and so that
> restriction is no longer in place.
> 
> They could even be distributed via composer.
> 
> Common functionality between languages
> ===
> 
> If you have some complex logic that needs to be replicated in several
> languages for whatever reason; implementing it several times over
> would lead to uncertain bugs and technical debt increasing heavily. If
> you could share the same logic amongst them all using FFI, then this
> is no longer an issue.
> 
> Example
> ===
> 
> Take an example of a rust program that takes two numbers in and gives
> you the sum of them.
> 
> ```rust
> #[no_mangle]
> pub extern fn add(a: i32, b: i32) -> i32 {
> a + b
> }
> 
> ```
> 
> with the Cargo.toml file containing:
> 
> ```
> [package]
> name = "math"
> version = "0.1.0"
> authors = ["Alex Bowers "]
> 
> [dependencies]
> 
> [lib]
> name = "math"
> crate-type = ["dylib"]
> ```
> 
> `cargo build --release` will create `.so`, `.dylib`, or `.dll` files
> depending on your system.
> 
> These should be usable within PHP using the exposed functions.
> 
> ```php
> $math = ffi("/path/to/math.so");
> $result = $math->add(1, 5);
> 
> echo $result; // 6
> ```
> 
> With the implementation at its most basic level, calling the `add`
> method with incorrect parameters would likely cause a segfault.
> 
> A way around that could be that the methods are not immediately
> exposed, but have to be configured.
> 
> Something like:
> 
> ```php
> $math = ffi("/path/to/math.so");
> $math->add(1, 5); // Throws RuntimeException, method not configured
> 
> $math->configure('add', int $a, int $b);
> 
> $math->add(1, 5); // 6
> $math->add('a', 5); Fatal error: Uncaught TypeError: Argument 1 passed
> to add() must be of the type integer, string given
> ```
> 
> Prior art:
> ===
> https://pecl.php.net/package/ffi - Last release > 13
> yearshttps://github.com/mgdm/MFFI - Not stable, last commit > 1 year,
> no releases
> 

Trying to add answers later today, in the meantime, please have a look
at https://github.com/m6w6/ext-psi


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

[Michael Wallner]

On 31/01/17 05:53, Stephen Reay wrote:
> Hi Andrea, All,
>
>> On 31 Jan 2017, at 08:12, Andrea Faulds  wrote:
>>
>> Is it necessary to introduce a new keyword, fn?
>>
>> I think you'd get a similar benefit from:
>>
>>function($x) => $arr[$x]
>>
>> Likewise, is it necessary to restrict auto-capture to the =>
>> syntax? Couldn't we allow the following?
>>
>>function ($x) {
>>return $arr[$x];
>>}
>>
>
> I agree that the `fn` keyword isn’t really necessary. I’ve never
> quite understood how arrow functions with implied returns etc are
> supposed to make for *more* readable code, but if they’re going to be
> part of the language please at least keep some consistency with
> regular closures.

Yes, I also think that keeping the function keyword would be better.

> 
> In the case that regular closures got auto-capture, would a
> `use($foo, $bar, $baz)` segment on a closure still be honoured (i.e.
> disable auto-capture), and would it have any impact (positive or
> negative) on performance/memory usage? After several years of JS
> closure ‘fun’ I kind of like that with PHP you only inherit the
> variables you explicitly `use()` in closures.

Wouldn't there be just too many existing closures, which do not use
`use` but (maybe) expect a clean scope?

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] imap_fetchbody() leaks memory

[Michael Wallner]

On 24/01/17 08:41, Leon Sorokin wrote:
> On 1/23/2017 2:45 PM, Michael Wallner wrote:
>> Just assigned that to me, I'll try to come to it the next few days.
> 
> Great, thanks!
> 

Hi, I've updated the bug: https://bugs.php.net/bug.php?id=73493

TL;DR

The c-client lib performs a lot of caching; use imap_gc() to clean those
caches from time to time.


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Re: [PHP-CVS] com php-src: Introduced "zend_type" - an abstraction for type-hinting representation.: Zend/zend_API.c Zend/zend_API.h Zend/zend_builtin_functions.c Zend/zend_compile.c Zend/ze

[Michael Wallner]

On 13/01/17 09:37, Dmitry Stogov wrote:
> Commit:141d1ba9801f742dc5d9ccd06e02b94284c4deb7
> Author:Dmitry Stogov  Fri, 13 Jan 2017 11:37:46 
> +0300
> Parents:   28391c30ca008013267592ab2a2eebce3da3f3b0
> Branches:  master
> 
> Link:   
> http://git.php.net/?p=php-src.git;a=commitdiff;h=141d1ba9801f742dc5d9ccd06e02b94284c4deb7

Hi Dmitry!

Maybe I'm missing something, but it seems that reallocated arg_infos leak:

$ memcheck sapi/cli/php -v
...
...
==16031==by 0x8BA068: zend_register_functions (zend_API.c:2273)
...
...
==16031== LEAK SUMMARY:
==16031==definitely lost: 3,888 bytes in 57 blocks
...

Each leak references line 2273 in zend_API.c pointing to this commit.

> Log:
> Introduced "zend_type" - an abstraction for type-hinting representation.
> 
> Changed paths:
>   M  Zend/zend_API.c
>   M  Zend/zend_API.h
>   M  Zend/zend_builtin_functions.c
>   M  Zend/zend_compile.c
>   M  Zend/zend_compile.h
>   M  Zend/zend_execute.c
>   M  Zend/zend_inheritance.c
>   M  Zend/zend_opcode.c
>   M  Zend/zend_types.h
>   M  Zend/zend_vm_def.h
>   M  Zend/zend_vm_execute.h
>   M  ext/com_dotnet/com_handlers.c
>   M  ext/opcache/Optimizer/dfa_pass.c
>   M  ext/opcache/Optimizer/zend_inference.c
>   M  ext/opcache/Optimizer/zend_optimizer.c
>   M  ext/opcache/ZendAccelerator.c
>   M  ext/opcache/zend_file_cache.c
>   M  ext/opcache/zend_persist.c
>   M  ext/opcache/zend_persist_calc.c
>   M  ext/reflection/php_reflection.c
> 
> 
> 


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] imap_fetchbody() leaks memory

[Michael Wallner]

Am 22.01.2017 00:15 schrieb "Leon Sorokin" :

Hey guys,

I filed bug 73493 [1] a couple months ago and there's no triage or visible
activity yet. Was hoping to get an update if possible.

I'm forced to download any large INBOX in batches with imap_close() &
imap_open() gymnastics to avoid chewing through 2GB+ of RAM.

thanks!

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



Just assigned that to me, I'll try to come to it the next few days.

Re: [PHP-DEV] Redesign of bugs.php.net

[Michael Wallner]

On 23/01/17 09:38, Maciej Sobaczewski wrote:
> 
> do you judge by the screenshots or an online demo?
> http://sobak.pl/php-bugs-mockup/bug.html
> 

Ah, yeah, thanks.
I was looking at the screenshot; it looks definitely better in Firefox.


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Redesign of bugs.php.net

[Michael Wallner]

On 23/01/17 08:22, Maciej Sobaczewski wrote:
> Hello,
> 
> I know it's bringing the same thread again but since my last post[1]
> I gathered some feedback on /r/php, including a few membmers of PHP.net.
> 
> https://github.com/Sobak/bugsnet-redesign-mockup this is the repo for
> my experimental approach on redesigning PHP.net. Short story: I took the
> design of php.net main website and after some modifications used it for
> our bugtracker.
> 
> Long story? All details are in the repo's README file. At the moment,
> this is just a static mockup but I'm ready to start feature branch on
> web/bugs as soon as I get your opinions.
> 
> Make sure to read section on Functional changes[2] I'd like to happen.
> I know these should be separated from the redesign but I limited myself
> to suggestions which are strictly connected to the interface/UX.
> 
> What are your thoughts? Does it look good? Can I start the branch or
> you prefer something entirely different/leaving it as-is?
> 
> CC'ed to php.internals to make sure it'll reach most of bugsnet users.
> 
> [1]: http://news.php.net/php.webmaster/25510
> [2]: https://github.com/Sobak/bugsnet-redesign-mockup#functional-changes
> 


Looks good to me, great work, thanks!
Just one thing, comments' text look tiny, don't they?

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] RFCs & Mailinglist

[Michael Wallner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Trying through NNTP this time:

Levi reported on IRC, that he's having issues with the ML again, and
asked for delaying any RFC communications until these issues are fixed:

 If anyone here *is* able to send messages can someone
please send a message to please delay RFC communications on the
mailing list, including moving to voting phase, until the
issues are fixed?


PS: Posting this message through my subscribed GMail address failed
with "550 5.7.1 reject mailfrom [sbl]".

- -- 
Regards,
Mike
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEHsPHHd1jWDGjN9aESA4+FLCkx8cFAlh0n+8ACgkQSA4+FLCk
x8e0vQgArIVrFPGhlhpNNhC/hWLc+jDZG3vTK5q/Fr5VIbsrB3uUfE0IJU/95cB+
yfJFXCLzPKcxnVtdyIJbz8jWYNPCQu7a61fUvnuWuhjByvL9APqYR8ozWSVdOS0C
lWU7GfI9KdtHccOLRiOEwFxyXn4CkKzc6SbjBnfpu4bAlBHmb12v+e0JTz44E5k/
O7UpZx3NBM+J4S7kb8jRLAaoogqcv+7X2tJAuPP6jtzHJM6H/3WLINw1s2P+lkqf
OWtFa+qReYvQKIeHOqIUofpeQxhDef1tAttZOF0mtzetE9qxzkekUFPzGAtSSlF+
iunh9tWeAJleJCglSEj2aecb607j4g==
=AkvK
-END PGP SIGNATURE-

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

Re: [PHP-DEV] Fwd: Monotonic Time

[Michael Wallner]

On 04/01/17 13:58, Niklas Keller wrote:
> Resending previous mail, because mail distribution was broken...
> 
> Morning Internals,
> 
> PHP doesn't currently have a way to access a monotonic time. There's a
> feature request in the bug tracker: bugs [dot] php [dot]
> net/bug.php?id=68029
> 
> A monotonic time is required to measure time intervals correctly, e.g. for
> implementing event loops based on stream_select. microtime() is affected by
> NTP and leap seconds and can therefore not be reliably used for measuring
> time intervals.
> 
...
> There's an existing PECL extension named hrtime: php [dot]
> net/manual/en/book.hrtime.php
> 
> I think we can reuse parts of it to implement a function in core to access
> a monotonic time, I don't think we need to merge the extension into core.
> 
> What do you think about adding such a function to the PHP core?

+1?

Actually, it seems, that hrtime doesn't let you access the current
value, which is, well, quite a major use case, isn't it?


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Looking for Z_TYPE_PP in all the wrong places.

[Michael Wallner]

On 14/12/16 14:17, Richard Quadling wrote:
> Hi.
> 
> I'm trying to find the replacement for Z_TYPE_PP (and several other
> Z_xxx_PP).
> 
> It seems these are no longer present in PHP7.

In PHP-7, you usually do not encounter zval**, so the _PP macros were
gone. Try _P(*zval) instead.

> 
> But, according to
> http://lxr.php.net/source/search?q=&defs=&refs=Z_TYPE_PP&path=&hist=&type=&project=PHP-MASTER,
> there is still 1 use case of this particular macro.

This just means that nobody ever built ext/odbc with the birdstep
driver. Unfortunate.

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC Proposal] Introducing New Global Variable to Support Other HTTP Methods and Content Types

[Michael Wallner]

Am 13.12.2016 14:45 schrieb "Dejan Stošić" :



*The problem*
Currently, PHP will parse the incoming HTTP request body only for GET
requests (and store the data in superglobal $_GET) and for POST requests
(and store the data in $_POST).
Additionally it will parse the data only for
*application/x-www-form-urlencoded* or *multipart/form-data *HTTP Content
types.
There are other 3rd party libraries and packages that enhance this and
enable parsing for other request methods and content types, but i feel like
this should have native support at this point.

*Goal*
Ideally, PHP should natively parse the incoming HTTP request body for all
request methods, not only for GET and POST. I guess that completely
replacing the $_POST and $_GET is out of the question as it would lead to
no backward compatibility. Maybe an additional superglobal could be
introduced ($_DATA)?



Have a look at http://pecl.php.net/apfd which triggers the request body
parser on any request method.

Also, http://pecl.php.net/json_post provides a content type handler for
JSON.

Parsing of the request body happens before entering userland, so providing
a pluggable interface (to userland) is not an option currently.

Cheers,
Mike



Thanks

Re: [PHP-DEV] Server-Side Request/Response Objects

[Michael Wallner]

On 26 09 2016, at 21:37, Paul Jones  wrote:
> 
> Hi all,
> 
> tl;dr: Gauging interest in an extension for server-side PHP request and 
> response objects (*not* HTTP messages per se; see below) prior to writing an 
> RFC for them on the wiki.
> 

Did you include pecl/http in your research?
It looks like it covers most of that already, if not all.
I know you said *not* HTTP messages per se, but I don’t see a lot of a 
difference.

Regards,
Mike



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] BAD Benchmark Results for PHP Master 2016-09-16

[Michael Wallner]

On 16/09/16 02:51, lp_benchmark_ro...@intel.com wrote:

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

Accessing those links has been generating a 404 for the last two
reports. Apprently the day of month is off by one in the URL.


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Michael Wallner]

Regards,
Mike



> On 02 09 2016, at 21:32, Davey Shafik  wrote:
> 
> Hi internals,
> 
> I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
> in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+)
> in their place.
> 
> https://wiki.php.net/rfc/deprecate-pear-include-composer
> 
> I highly recommend reading the twitter poll and accompanying thread at
> https://twitter.com/dshafik/status/756337267547832320
> 
> I believe that pickle solves the issues with regards to pecl, and have run
> the idea passed Jordi and Pierre. Both are fine with this RFC. :)
> 
> I understand that adding in composer/pickle is just setting us up for
> having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
> I've proposed the voting reflect that some people will just want to
> deprecate/remove pear/pecl and not replace them at all.
> 
> I'm also proposing voting choices around the optional/default introduction
> of composer/pickle.

+1 on stabbing the PEAR installer from the source distribution.
-1 on adding anything else. Composer is as easy to install separately as PEAR 
from their origin as well as from OS distributions these days.

On a side note, we should look into evolving ext/phar to a plugin based system, 
not the hard coded foreign feature sink it currently is (with regards to 
compression and signing support at first, with the underlying file format being 
next).

Cheers,
Mike





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

[Michael Wallner]

On 22/08/16 12:44, Rowan Collins wrote:

> As far as I can see, these functions exist because the XML parser
> infrastructure needed them, and someone thought it might be handy to
> expose them to users. Funnily enough, the internal versions actually
> take a parameter for the target encoding, but only support US-ASCII and
> 8859-1: https://github.com/php/php-src/blob/master/ext/xml/xml.c#L283
> 
> If anything, they should probably have a "str_" prefix, and maybe even
> be moved into the string section of the source, exposed in such a way
> that the XML parser can still make use of them.

Thanks for looking deeper. That makes even more sense now.


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

[Michael Wallner]

On 22/08/16 03:52, Yasuo Ohgaki wrote:

> I'll update the RFC to have aliases rather than removing. Since these
> are XML module functions, the name would be xml_latin1_to_utf8() and
> xml_utf8_to_latin1(). Suggestions for names are appreciated.

+1, I think those are the names to go.

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] ext/pcntl asynchronous sugnal handling

[Michael Wallner]

> On 23 06 2016, at 14:28, Nikita Popov  wrote:
> 
> On Thu, Jun 23, 2016 at 2:19 PM, Dmitry Stogov  wrote:
> 
>> 
>> The simple patch uses the recently added into Zend Engine ability and
>> allows asynchronous signal handling without extra ZEND_TICKs (without any
>> run-time overhead).
>> 
>> 
>> https://gist.github.com/dstogov/01d1002c1785f82eaac4b937ccaf418f
>> 
>> 
>> Accepting this would probably need RFC.
>> 
> 
> Line 43 should probably call orig_interrupt_function.
> 
> I'm +10 on this change. Using ticks for interrupt handling was horrible,
> and since PHP 7 doesn't really work anyway.
> 

Another +10 here!



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

[Michael Wallner]

On 12/05/16 13:36, Lester Caine wrote:
> On 12/05/16 11:21, Davey Shafik wrote:
>> E.g. the behavior of passing executing with a null value for the
>> argument is something you should be consciously making a decision on,
>> and passing in null explicitly.
> 
> I was actually getting the logic wrong... the problem with this proposal
> is that I HAVE to add the '?' for many of my libraries to continue to
> work simply because they do handle the null case. So what was a working
> system is broken by this change.
> 

So you already have function foo(Foo $foo = null)?
No need to change anything.

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

[Michael Wallner]

On 11/05/16 12:26, Lester Caine wrote:
> On 10/05/16 21:26, Levi Morrison wrote:
>> It can affect the results.
>>
>> function foo(?Foo $param) {}
>>
>> If any code out there is calling foo with null then that code will now
>> break if you remove the question mark.
> 
> Cart before Horse comes to mind ...
> 
> If the function is going to fail if you pass in a null ... you check for

Why do you assume it'll fail?

> the null before calling it. OK the '?' is a flag that you need to do
> that, but you really need proper documentation as to just what Foo
> expects. If I've handled the null case situation, the ? is redundant?
> 
> I'm still failing to see an overall picture of what people are trying to
> achieve. Adding errors means that those errors need to be handled. If
> the function gets a 'null' then there is a reason, and either the
> function should not have been called ... workflow failed ... or the
> function should simply handle the 'null' case. If the '?' throws an
> error the workflow is broken after the event where a user code warning
> would be more helpful.
> 

function foo(?Foo $param)

is equivalent to

function foo(Foo $param = null)

except the former does not provide a default, i.e. it requires an
argument being passed to a call to foo().

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Pipe Operator

[Michael Wallner]

On 30/04/16 20:57, Sara Golemon wrote:
> On Sat, Apr 30, 2016 at 11:41 AM,   wrote:
>> God I hate crap software ... TRYING to reply without top post ... but 
>> Samsung is incapable!
>>
>> What I was trying to comment on was that trapping that no result is returned 
>> may be what is needed, so handling the empty array rather than a null return 
>> just means having to remember what you do use :(
>>
> What follows is a terrible idea and I don't mean to propose it as a
> solution, but to spark further conversation:
> 
> $result = getData()
>   ?> doStuffWith($$)

I thought this was the "PHP, stop messing around with my HTML" operator?

>   :> actOnFailureOf($$);
> 
> Basically, a chaining ternary such that the result of the condition
> expression propagates to the true/false expressions.  Not really the
> same feature at this point, but a similar chaining-friendly take on
> the standard ternary.  Just thinking out loud...


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [VOTE] 7.1 RMs selection

[Michael Wallner]

On 26/04/16 17:59, Anatol Belski wrote:
> Hi,
> 
> herewith I would like to call everyone to go vote for the 7.1 RMs team. The
> poll is opened under
> 
> https://wiki.php.net/todo/php71
> 
> The vote starts on 2016-04-26 and end on 2016-05-03 (both at a time 6pm).

Thanks!

PS: If anyone is wondering WTF is going on (like I did), have a look at
the (recent messages of the) "PHP 7.1 roadmap" thread!

Cheers!

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][DISCUSSION] Session ID without hashing

[Michael Wallner]

On 08/04/16 04:17, Yasuo Ohgaki wrote:

> PRNG like /dev/urandom is supposed to be secure, but fair point. It
> may be good idea keeping old hash based session ID just in case
> someone find vulnerability. I suppose it's unlikely with modern PRNGs,
> though.

I've come to think that "unlikely" is still a bad precondition with
regards to security... :)

> 
> If we have to care about PRNG state exposure, code may be changed to
> read random length from RPNG. This would be good enough mitigation. I
> would like to hear from PRNG experts if this is good enough. (or not
> needed)
> 
>> Second, I do not see why we need to do maximum
>> breakage change if we could just make an identity "hash" function and
>> support both cases. "Session generation performance" does not have a lot
>> of meaning here - I'd be very surprised to see any application that is
>> bound by the speed of generating session IDs.
> 
> w/ Patch: Requests per second: 2278.59 [#/sec] (mean)
> w/o Patch: Requests per second: 899.36 [#/sec] (mean)
> (This is CLI server and "ab -c 20 -n 10" result on Core i7 4770s Linux)
> 
> I didn't expect this much difference, but this is the result. Since
> security experts advise to change session ID relatively high frequency
> (few minutes to half an hour), this difference may be noticeable apps
> returning cached JSON. I know apps that change session ID on every
> request. (This should be done with caution. Otherwise, you may
> experience lost sessions a lot due to race conditions) Such apps will
> see performance gain.

This RPS change is the result of just omitting hashing of the session id?


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Michael Wallner]

> On 18 02 2016, at 20:33, Andrea Faulds  wrote:
> 
> Hi Colin,
> 
> Colin O'Dell wrote:
>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>> keyword.
> 
> I don't have a strong opinion on that, I guess I'm in favour. It seems like a 
> fairly harmless deprecation.
> 
> Though if we do get rid of the var syntax, I'd like it if we kept the 
> reserved word, because it still might be useful in future for typed variables 
> or different variable scoping.
> 

That’s an interesting idea, -1 on the original proposal, though.

Regards,
Mike



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

Re: [PHP-DEV] unpack()

[Michael Wallner]

> I think the requested feature may be really useful.
> 
> And the implementation is really simple 
> https://gist.github.com/dstogov/edbb1efcd1e9701e75ab 
> 

There seems to be a typo at 
https://gist.github.com/dstogov/edbb1efcd1e9701e75ab#file-unpack-diff-L23 

where ‘&&’ should be ‘||’ in the ‘if’ condition.

> 
> I think, committing this into master doesn't require RFC and voting.
> 
> Anyone objects?

+1

Regards,
Mike

Re: [PHP-DEV] [RFC] Warn about invalid strings in arithmetic (moving backtodiscussion)

[Michael Wallner]

> On 05 02 2016, at 11:49, Andrea Faulds  wrote:
> 
> Hi again,
> 
> Andrea Faulds wrote:
>> There is one unresolved issue with the current patch that the RFC
>> doesn't address, so I'll ask about it here.
>> 
>> As part of supporting exponent notation in all remaining integer
>> operations (casts, operators), I would like to have intval() support it,
>> to match the `(int)` cast.
>> 
>> For strings, intval() doesn't use the normal zval-to-long conversion
>> functions (zval_get_long/convert_to_long), but instead uses strtol
>> directly. This is so it can support multiple bases, e.g. intval("10",
>> 12) results in 12.
>> 
>> In order for intval() to support exponent notation, I'd have to change
>> it to now call zval_get_long, but that function doesn't support
>> non-decimal bases, nor does is_numeric_string_ex, which underlies it.
>> 
>> So, we'd either have to make intval() only support exponent notation for
>> base 10, an unfortunate inconsistency, or we could not touch intval(),
>> but then intval($a, 10) would no longer act the same as (int)$a.
>> 
>> I'm leaning towards the first choice, but I'd like to hear what the
>> mailing list thinks. Either way we have a new inconsistency. But then,
>> intval() has unfortunate behaviour with its base parameter anyway, in
>> that ignores the base for non-string input. That means that intval(123,
>> 8) and intval("123", 8) aren't equivalent, a violation of weak typing.
>> 
>> Anyway, please tell me your thoughts.
> 
> There hasn't been any response to this so far on the mailing list, 
> unfortunately. In discussions I've had elsewhere, making it apply to intval() 
> but only for base 10 has seemed to make sense. Both ways result in 
> inconsistency.
> 
> So, I've updated the RFC to clarify that it does apply to intval(), but only 
> where $base is 10, and also to clarify that settype() should be affected.


To be honest, I had not even memorised intval() supports a base, but that we 
have base_convert().

I’d opt for dropping base convert support from intval(), but that’s obviously 
not possible, because PHP-7.1 is the target for this RFC.

Cheers,
Mike

Re: [PHP-DEV] Re: [RFC] Warn about invalid strings in arithmetic (moving back todiscussion)

[Michael Wallner]

On 27/01/16 01:54, Levi Morrison wrote:
> I personally consider the new changes with fractional and scientific
> notation strings and integer operators to be the more important
> change. Thanks to everyone who identified and fixed this
> inconsistency.
> 
> Does anyone have any good ideas on how to prevent strtol and strtod
> from being re-introduced to the repository? I could potentially see
> this happening.
>

Pardon? There's no need to "ban" any standard functions, just make sure
you always use is_numeric_string when dealing with userland. It's
perfectly fine to use strtol, when you know what you're doing.
Unfortunately, it seems, we don't have a suitable place to put that notice.

Kudos to everyone discovering that.

-- 
Regards,
Mike

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

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Michael Wallner]

On 21/01/16 06:36, Xinchen Hui wrote:
> Hey:
> 
> On Wed, Jan 20, 2016 at 7:05 PM, Michael Wallner  <mailto:m...@php.net>> wrote:
> 
> On 08/12/15 10:56, Dmitry Stogov wrote:
> > Hi Sean,
> >
> > The PR has been merged into master.
> > Please update the RFC accordingly.
> > Thanks to Nikita and Xinchen for code review and suggestions.
> >
> 
> 
> This patch seems to cause problems for me with registering constants on
> internal interfaces; see bug #71413 https://bugs.php.net/71413
> 
> this should be fixed in :
> https://github.com/php/php-src/commit/62c1c11ad34103729988df9edea343337a900ba9

Confirmed. Thank you!


-- 
Regards,
Mike

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

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Michael Wallner]

On 08/12/15 10:56, Dmitry Stogov wrote:
> Hi Sean,
> 
> The PR has been merged into master.
> Please update the RFC accordingly.
> Thanks to Nikita and Xinchen for code review and suggestions.
>


This patch seems to cause problems for me with registering constants on
internal interfaces; see bug #71413 https://bugs.php.net/71413


-- 
Regards,
Mike

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

Re: [PHP-DEV] [RFC] Allow specifying keys in list()

[Michael Wallner]

On 17/01/16 03:32, Andrea Faulds wrote:
> Hi everyone,
> 
> Here's an RFC that would extend the syntax of list() to be more useful
> with associative arrays:
> 
> https://wiki.php.net/rfc/list_keys
> 
> Please read it and tell me your thoughts.

Hi!

I found the idea convincing from the first read, but maybe it's just my
mind's assumptions about list() that I dislike the resulting syntax,
yet, it seems to be the logical choice.

So, maybe I'm just trying to say, that I don't like list() to be reused
for that, but I don't have any better idea otherwise.

-- 
Regards,
Mike

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

Re: [PHP-DEV] What's up with gcov.php.net?

[Michael Wallner]

> On 30 12 2015, at 22:34, Andrea Faulds  wrote:
> 
> Hi everyone,
> 
> If any of you have looked at http://gcov.php.net any time in the last three 
> years, you'll probably have noticed an alarming and inexplicably high number 
> of test failures. And if you've looked at Travis, you'll have seen much more 
> reasonable numbers (i.e. usually zero).

A guess might be, that many of the tests run on gcov are disabled on travis. 

> 
> So, I'd like to ask, why does gcov.php.net always show such high numbers, and 
> apparently has things that are fixed show up as broken, and secondly, since 
> we use Travis for continuous integration these days, why is the box even 
> still running?

gcov is about coverage too, so…

Anyway, you’ve probably got to talk to Nuno; IIRC he was/is managing the gcov 
box.

Cheers,
Mike


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

Re: [PHP-DEV] [RFC] Number Format Separator

[Michael Wallner]

See also "[PHP-DEV] Digit separators for numeric literals" from Feb, 19th.

Re: [PHP-DEV] Scalar type hints and scalar type name aliases cause confuson

[Michael Wallner]

On 12/10/15 21:23, Andrea Faulds wrote:
> Hi,
> 
> As PHP 7 currently is, if you write this:
> 
> public function foo(): integer {
> return 12;
> }
> $bar = foo();
> 
> you'll get the following error:
> 
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of integer, integer returned
> 
> Similarly, if you were to write this:
> 
> public function foo(): boolean {
> return true;
> }
> $bar = $foo();
> 
> you'd get this:
> 
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of boolean, boolean returned
> 
...
> Alongside or instead of that, though, we can do two other things to make
> this situation better.
> 
> First, we could make type error messages use 'int' and 'bool'. This
> feels somewhat wrong to me since integer and Boolean are the proper
> English names for the types. But we do use the short names in some other
> places, like var_dump, so this isn't so bad. This way, we get this
> slightly clearer error:
> 
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of integer, int returned
> 
> Second, we could add a helpful note to the TypeError message when the
> type hint is for a class named 'integer' or 'boolean' and the value
> passed was an integer or Boolean, respectively. My patch (based on
> Anthony's original) for the earlier Scalar Type Hinting with Cast RFC
> did this. This would make things even clearer:
> 
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of integer, int returned (did you mean to use the type hint
> 'int'?)
> 
> Even if we can't reserve the names, I hope we can do the two other
> suggestions in time for release.

Additionally, we could say "instance of class ...".


-- 
Regards,
Mike

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

Re: [PHP-DEV] Re: [RFC] [DISCUSSION]: Closure from callable

[Michael Wallner]

On 4 Oct 2015 21:50, "Stanislav Malyshev"  wrote:
>
> Hi!
>
> > I don't like that it's a function. Closure is a class, classes can have
> > static and instance methods, and closure() looks like something that
> > should be a method on Closure. In fact, it creates a closure, which a
> > constructor would usually do. If we want to make it avoid duplication,
> > okay, then it could be a static method. But I'm unconvinced it should be
> > a function. Constructors go in their classes, we don't leave them lying
> > around as global functions. That's messy and inconsistent.
>
> Agree. Closure::fromCallable sounds like a good option.
> That being said, I'm not sure how much need is for this - i.e. you can
> always make a closure by just doing function() { return $this->blah(); }
> if you need it. But the bigger question would be why you need more
> specific type (Closure) instead of more generic (callable) and aren't
> you overspecifying in that case?
>
> And if we're into performance optimization - which should almost never
> be done on language construct level, because performance considerations
> vary and language constructs are forever - then it would be much better
> to look into tail call optimizations. That would solve the barrier
> between [$this, "foo"] and function() { return $this->foo(); } in many
> practical cases.
>

I think the origin of this intention is, that calling a callable just by
`$callable()` does not work consistently -- see the othe RFC by Dan -- and
that call_user_func() suffers from a (mythical?) performance issue.

Re: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

[Michael Wallner]

On 29/09/15 16:23, Dan Ackroyd wrote:
> Hello internals,
> 
> I'd like to start a discussion of a proposal to allow closures to be
> created in user-land without having to use a whole lot of reflection
> code.
> 
> https://wiki.php.net/rfc/closurefromcallable
> 
> Thanks to Joe and Bob for the assistance in the patch.

+1, I'm not sure it belongs into ext/reflection, though?


-- 
Regards,
Mike

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

Re: [PHP-DEV] recommended .gitignore for PHP/PECL extensions

[Michael Wallner]

On 25 Sep 2015 21:10, "j adams"  wrote:
>
> I have made good progress on a PHP extension and I'd like to post it on
> github to get some review and help from some others. The folder has quite
a
> few files and I'm hoping to avoid putting anything in git that doesn't
need
> to be there.
>
> I see that php 5.6 has this .gitignore file:
>
http://git.php.net/?p=php-src.git;a=blob_plain;f=.gitignore;hb=f5751638dbd77136ce5c90e7d8bd090aa655c2a3
>
> But that one is for the root of the php project. I just want my git repo
to
> contain my code in the ext/extension-name folder.
>
> Can anyone recommend a good .gitignore file for extensions? I looked
around
> in a bunch of the PECL dirs and found a couple:
> http://git.php.net/?p=pecl/languages/v8js.git;a=tree
> http://git.php.net/?p=pecl/networking/ssh2.git;a=tree

The "standard" .gitignore is generated by the ext_skel script, see
http://git.php.net/?p=php-src.git;a=blob;f=ext/ext_skel;h=a1c64640ae63b15149add0f1e94378edc7291a38;hb=HEAD

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

[Michael Wallner]

> On 19 09 2015, at 23:22, Rowan Collins  wrote:
> 
> On 19 September 2015 15:49:55 BST, Lester Caine  wrote:
>> On 19/09/15 13:15, Rowan Collins wrote:
>> If there was a bug with 'isset' it is that it returns false for a
>> variable that IS SET to null.
> 
> I honestly think that the only problem there is the name. If instead of 
> isset() and empty() we had quiet_is_null and quiet_boolval, nobody would be 
> the slightest bit surprised by their behaviour, and people looking to see if 
> an array key exists would be more likely to find array_key_exists.
> 
> 
>> if the variable does not exist there is no way of testing for that
>> state
>> prior to calling is_null()
> 
> Correct, there is no way of testing for that full stop.

There is, though, not sure if already mentioned:

array_key_exists(“var”, get_defined_vars()) && is_null($var)



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

Re: [PHP-DEV] Consolidation of Traversable and array operations

[Michael Wallner]

On 16/07/15 11:26, Rowan Collins wrote:
> Benjamin Eberlei wrote on 15/07/2015 21:19:
>>
>> But instanceof and anything related to Reflection or get_class or
>> relevant code will fail on array.
> 
> 
> Ah, yes, I hadn't thought of reflection type things. I don't think
> instanceof would be a problem, because checking for any class or
> interface other than Traversable would correctly return false; not sure
> if it would make sense for "array() instanceof Traversable" to return
> true or not...
> 

Maybe some pseudotype like callable (e.g. iteratable) makes more sense then?


-- 
Regards,
Mike

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

Re: [PHP-DEV] Consolidation of Traversable and array operations

[Michael Wallner]

On 15/07/15 13:28, Tjerk Meesters wrote:
> Hi!
> 
> A few weeks ago I resurrected a two year old proposal for adding two array
> functions, namely array_every() and array_some(), modelled after their
> JavaScript equivalent.
> 
> https://github.com/php/php-src/pull/1385
> 
> ...
> 
> Let me know what you think!
> 

Sounds awesome!

-- 
Regards,
Mike

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

Re: [PHP-DEV] LDAP module test suite

[Michael Wallner]

On 15/06/15 15:43, Chris Wright wrote:
> On 15 June 2015 at 14:02, Côme BERNIGAUD 
> wrote:
> 
>> Hello,
>>
>> What is the needed configuration to be able to run the whole LDAP test
>> suite?
>> It connects with "cn=Manager,dc=my-domain,dc=com" but then tries to create
>> "dc=my-domain,dc=com".
>> How can "cn=Manager,dc=my-domain,dc=com" exist if "dc=my-domain,dc=com"
>> does not?
>>
>> Is there any information about a known configuration to be able to pass
>> all LDAP tests?

Check out ext/ldap/tests/connect.inc; you can pass various parameters
from the environment.

>>
>> Côme
>>
>> PS: Also, is there a way to launch only ldap tests with PHP Makefile?
>>
>>
> You can't do it with "make test" afaik, but you can manually invoke
> run-tests.php and pass it a path, e.g. php run-tests.php ext/ldap/
> 

You can run `make test TESTS=path/to/ext/ldap`.


-- 
Regards,
Mike

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

Re: [PHP-DEV] Maintaining LDAP module

[Michael Wallner]

> On 10 06 2015, at 12:21, Côme BERNIGAUD  wrote:
> 
> Hello,
> 
> I intend to work on LDAP module, starting by trying to get rid of obsolete 
> method calls. (starting by https://bugs.php.net/bug.php?id=69471 )
> 
> I already have appropriate CVS rights but I’m not sure which branch I should 
> commit into.
> The git workflow says to commit in PHP-5.3 and then merge on your way down to 
> 5.6, but I’m not sure 5.3 is even still maintained?

I’d say go with PHP-5.6 only (and master). Systems depending on older PHP 
version will probably also depend on older libraries.

Regards,
Mike


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

Re: [PHP-DEV] Method call overhead

[Michael Wallner]

> On 03 06 2015, at 05:30, Bishop Bettini  wrote:

> My question though is on relative times.  Method call overhead is
> consistently 50% to 150% over a direct call.  Is my experiment invalid, or
> is this overhead expected?  Is the overhead in the allocation,
> deallocation, GC?

I’suggest you use a tool like valgrind’s callgrind (and visualize with e.g. 
kcachegrind).

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

Re: Fwd: [PHP-DEV] [RFC] [PHP 7.1] libsodium

[Michael Wallner]

On 21/05/15 09:49, Peter Petermann wrote:
> Hi Scott,
>
> I personally think the RFC is a bit short,
> also I just had a very brief look at the documentation of the
extension in
> question, and find its API a bit strange,
> whats up with having everything in static method calls?
>
> regards,
> PP
>
> 2015-05-21 3:15 GMT+02:00 Scott Arciszewski :
>
>> The current state of cryptography in PHP is, well, abysmal. Our two main
>> choices for handling symmetric cryptography are libmcrypt (collecting
dust
>> since 2007) and openssl, which lacks a streaming API (e.g.
mcrypt_generic)
>> and GCM support.
>>
>>
>> I think now is a good time to talk about the possibility of making
>> libsodium a core PHP extension, depending on where things are when we
near
>> the 7.1 feature freeze.
>>
>> I've just opened an RFC for precisely this purpose:
>> https://wiki.php.net/rfc/libsodium
>>

Yes, the choice of API looks pretty awkward; if we could settle on
PHP-5.6+, change Sodium to a namespace and all methods to functions therein.

-- 
Regards,
Mike

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

Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion

[Michael Wallner]

On 22 Apr 2015 10:27, "Alexander Moskalev"  wrote:
>
> Thanks to all for feedback!
>
> Let's try to integrate new feature to old class.
> We have constructor in CURLFile with one required parameter: $filename .
> To avoid BC break we cannot replace this parameter. So  I suggest to do it
> optional and add setBuffer() method.
>
> So we can create CURLFile with empty parameters in constructor and fill it
> with setters.
> Have two more questions:
> 1) If we not fill all options or fille not compatible options, when we
must
> throw error? ? And what level of this error? (Sorry, I'm just php coder
and
> know about C language and php source so little)
> For file from disk(or other source) required $filename. For file from
> buffer required $buffer and $postname.
> 2) Curently CURLFile cannot be unserialized, because it contains $filename
> (see source code). How it compatible with our dicussion?
>

Why not a ctor as in:

function __construct ($filename, $buffer = null) {
if (isset ($ buffer)) {
// use $ buffer
} else {
// use file contents
}
}

The file name parameter can be of use anyway for posted file contents from
buffer.

Cheers,
Mike

Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version

[Michael Wallner]

> On 01 04 2015, at 18:28, François Laupretre  wrote:
> 
>> De : Ferenc Kovacs [mailto:tyr...@gmail.com]
>> 
>> I could accept any decision between holding off new features until next 
>> minor/major and allowing features explicitly without going through an RFC, 
>> but I 
>> want to have an explicit definition on what is allowed and how should the 
>> case-
>> by-case process work.
> 
> The release process document is clear : "New features or additions to the 
> core should go through the RFC process." (hopefully considering the 'core' as 
> the whole PHP distribution). It would be better using "must" instead of 
> "should" but it is quite clear.
> 
> So, providing "a room for exceptions on a case by case basis and only for 
> small self-contained features and additions" does not mean that these 
> features don't have to go through an RFC. There is nothing to add to the 
> rules, we just need to have them enforced by people who currently merge new 
> features without demanding an approved RFC. If everyone respects the rules, 
> the 'case by case process' is clear, it means 'approved through an RFC'. Only 
> bug fixes with no side effect can be merged without an RFC.
> 
> So, once again, as https://github.com/php/php-src/pull/1145 clearly did not 
> follow the rules and was not approved in any way, I'm asking whoever merged 
> it to revert the change and ask the author to go through an RFC.

It’s not a secret that I’m not a big fan of too much bureaucracy, we’re still 
humans that can discuss and argue without a formal RFC.
If anything develops to be controversial, let’s go through an RFC, if not, then 
fine and let them go ahead.


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

Re: [PHP-DEV] Deprecate setlocale?

[Michael Wallner]

> On 01 04 2015, at 18:15, 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.
> 
> https://bugs.php.net/bug.php?id=59571 - breaks Imagick
> https://bugs.php.net/bug.php?id=54538 - breaks NumberFormatter
> https://bugs.php.net/bug.php?id=66108 - breaks constants
> https://bugs.php.net/bug.php?id=67127 - breaks DateTime
> https://bugs.php.net/bug.php?id=69348 - breaks MySQL
> 
> And there are quite a few other bug reports where setlocale is doing
> exactly what it is meant to do, but the unexpected side-effects are
> catching people out.
> 
> We have libraries that ship with PHP for formatting dates, numbers etc
> that actually work, and don't break other libraries.
> 
> So two questions:
> 
> i) Are there any reasons why we couldn't or shouldn't plan for
> removing setlocale at some point in the future? i.e. does it do
> something that isn't supported by other libraries in PHP?
> 

-1
I don’t hink that we should restrict access to standard library functions just 
because something might break due to usage under wrong assumptions.

> ii) If it's not possible (or desirable) to remove it, how could we
> increase the warning level against using it?


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

Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version

[Michael Wallner]

On 30/03/15 12:04, Ferenc Kovacs wrote:
> Hi,
> 
> I know that our official release process allows that, but there are some
> reasonable arguments against doing that and this topic was brought up
> multiple times related to specific fixes.
> I have two open PRs like that:
> https://github.com/php/php-src/pull/1204
> https://github.com/php/php-src/pull/969
> and of course there are a bunch of similar ones from other people, and
> there are cases when somebody simply pushes a change like that, other times
> somebody points out that it should require an RFC(
> https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
> most of the times we simply don't know what to do, and eventually we just
> let the PR/patch to rot and die.
> I would like to know if we can come up with a rule which can have consensus
> behind it, and maybe formalize it as an extension to our current
> releaseprocess rfc.
> 
> What do you think?
> 

How about:

It's okay, if it does not need `version_compare(PHP_VERSION)` but can be
tested by e.g. `defined("SOME_CONSTANT")` or `function_exists("fn")`?

-- 
Regards,
Mike

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

[PHP-DEV] [RFC][ACCEPTED] Continue Output Buffering

[Michael Wallner]

Hi, I was late closing the vote on rfc:continue_ob, but there was only
one yay in the last two days, anyway.

The change was accepted with 100% yes votes, and has just been committed.

-- 
Regards,
Mike

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

Re: [PHP-DEV] phar_rename_archive() bug fix for PHP7

[Michael Wallner]

On 17/03/15 15:55, Ralph Schindler wrote:
> hi all,
> 
> Phar::convertTo*() methods have a design flaw such that phar files can't
> be successfully converted and retain the proper file suffix at the same
> time when the base name contains dots.  An expression of this is
> attempting to convert something-v3.0.0.phar to say a tar.gz via
> convertToExecutable(Phar::TAR, Phar::GZ);
> 
> My original patch respected BC when it was destined for PHP5, but now
> I've cleaned it up and removed the retention of BC behavior, and I
> intend it to be merged to PHP7 only.  As such, existing tests also
> needed modification.
> 
> I'd like some discussion, code review ... and if no objections, some
> karma to commit this to master.  The PR is here:
> 
> https://github.com/php/php-src/pull/297

Hi Ralph!

I recently stumbled over that issue, too; thanks for looking into it.

Looking at the patch, it seems, that some handling for bzip2 archives is
missing; I think if there are special cases for .tar, .tgz and .zip,
there should also be a case for .tbz2 (.tar.bz2).

-- 
Regards,
Mike

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

Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes

[Michael Wallner]

> On 15 03 2015, at 17:09, Dan Ackroyd  wrote:
> 
> Hi List,
> 
> The 'Constructor behaviour of internal classes' RFC is now in voting.
> Please note, it's the coding standard that is being voted on. If
> anyone thinks I've implemented the changes in a way that is less
> awesome then there is no reason the changes couldn't be improved.
> 
> Additionally, while writing the change I noticed some things that were
> already present in the code, that are outside the scope of the RFC but
> ought to be fixed for the release of PHP 7.
> 
> * Multiple examples of a generic Exception being thrown rather than a
> specific exception being thrown.
> 
> * Code generating an error notice and throwing an exception. It should
> be one or the other, not both.
> 
> * The text of exceptions in Intl not always being as informative as
> the error message, which could be improved.
> 
> But as I said, the vote is on whether the standard behaviour of either
> returning a working instance or throwing an exception, is the standard
> behaviour we want in PHP.
> 
> 

For the lazy people, like me:
https://wiki.php.net/rfc/internal_constructor_behaviour#voting 

Re: [PHP-DEV] Voting irregularities

[Michael Wallner]

>> 
>> Is there a way to check when someone got a php.net account/karma?
>> 
>> 
>> http://people.php.net
>> 
> 
> I am aware of this, but unless I just missed it that site doesn't show
> *when* they got an account.

Oh, sorry! I thought it reads something like “Account opened: Y-m-d” but that’s 
on the PECL site.



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

Re: [PHP-DEV] Minimum version of GCC required to build PHP

[Michael Wallner]

> On 15 03 2015, at 16:36, Sebastian Bergmann  wrote:
> 
> Am 15.03.2015 um 15:34 schrieb Sebastian Bergmann:
>> I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related
>> to the usage of intptr_t (see http://pastebin.com/9Gn0AAXA).
> 
> Over in Room 11, Michael just pointed out that this could be related
> to php_stdint.h.

Yes, we could probably just add a check whether intptr_t is defined and if not 
do so according to the bit width of the platform.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Voting irregularities

[Michael Wallner]

> On 15 03 2015, at 16:23, Levi Morrison  wrote:
> 
> On Sun, Mar 15, 2015 at 8:29 AM, Michael Wallner  wrote:
>> 
>>> On 15 03 2015, at 15:19, Anthony Ferrara  wrote:
>>> 
>>> All,
>>> 
>>> I ran some numbers on the current votes of the dual-mode vote right
>>> now. There were a number of voters that I didn't recognize. So I
>>> decided to pull some stats.
>>> 
>>> The following voters never voted before the dual-mode RFC went up:
>>> 
>>> dom - no
>>> eliw - no
>>> kguest - yes
>>> kk - no
>>> nohn - no
>>> oliver - yes
>>> richsage - yes
>>> sammywg - no
>>> spriebsch - no
>>> srain - no
>>> theseer - no
>>> zimt - no
>>> 
>>> Some of these names I recognize from list (sammywg and eliw), but many I do 
>>> not.
>>> 
>>> The interesting thing happens when you look at the voting direction.
>>> 
>>> Currently, the RFC is slightly losing 70:37 (65.4%).
>>> 
>>> If we look at percentages, 4.2% of yes voters have never voted in a
>>> prior RFC. But a whopping 24.3% of no voters have never voted before.
>>> 
>>> If we adjust the votes to remove these "never voted" accounts, it
>>> stands at 67:28. Which is 70.5%. Which is basically where the vote was
>>> prior to the competing RFC opening.
>>> 
>>> I'm not saying that all of these are bad votes. Nor that they
>>> shouldn't be counted. I think it does raise a significant question
>>> around the voting practices.
>>> 
>>> Something that I think we need to discuss as a group.
>>> 
>>> So consider that discussion open.
>> 
>> Jeez, that is becoming ridiculous. So, if you’re that good in counting, how 
>> many did not vote before STHv0.3?
> 
> Is there a way to check when someone got a php.net account/karma?

http://people.php.net <http://people.php.net/>

Re: [PHP-DEV] Voting irregularities

[Michael Wallner]

> On 15 03 2015, at 15:19, Anthony Ferrara  wrote:
> 
> All,
> 
> I ran some numbers on the current votes of the dual-mode vote right
> now. There were a number of voters that I didn't recognize. So I
> decided to pull some stats.
> 
> The following voters never voted before the dual-mode RFC went up:
> 
> dom - no
> eliw - no
> kguest - yes
> kk - no
> nohn - no
> oliver - yes
> richsage - yes
> sammywg - no
> spriebsch - no
> srain - no
> theseer - no
> zimt - no
> 
> Some of these names I recognize from list (sammywg and eliw), but many I do 
> not.
> 
> The interesting thing happens when you look at the voting direction.
> 
> Currently, the RFC is slightly losing 70:37 (65.4%).
> 
> If we look at percentages, 4.2% of yes voters have never voted in a
> prior RFC. But a whopping 24.3% of no voters have never voted before.
> 
> If we adjust the votes to remove these "never voted" accounts, it
> stands at 67:28. Which is 70.5%. Which is basically where the vote was
> prior to the competing RFC opening.
> 
> I'm not saying that all of these are bad votes. Nor that they
> shouldn't be counted. I think it does raise a significant question
> around the voting practices.
> 
> Something that I think we need to discuss as a group.
> 
> So consider that discussion open.

Jeez, that is becoming ridiculous. So, if you’re that good in counting, how 
many did not vote before STHv0.3?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] [RFC] continue output buffering

[Michael Wallner]

Voting just started on https://wiki.php.net/rfc/continue_ob 

I’ll close the poll in a week.

Thanks,
Mike

Re: [PHP-DEV] php_stream_read(...) may return less than expected

[Michael Wallner]

On 12/03/15 14:28, Umberto Salsi wrote:
> Hi all,
> I'm not a PHP internals developer, but this might be a bug spread here and
> there in the source. This coding pattern:
> 
> if(php_stream_read(..., n) != n){
> php_error_docref(NULL TSRMLS_CC, E_SOMETHING, "Read error!");
> 
> seems wrong to me because there might be streams that returns less than
> n bytes at once. When exactly n bytes are expected, not more not less,
> a function similar to this one should be used instead:
> 
> int php_stream_read_fully(..., int n){
>   continue calling php_stream_read() until exactly n bytes are
> collected, or a premature EOF, or I/O error
> }
> 
> I ran into this issue passing a custom stream to getimagesize():
> 
> getimagesize("myprotocol://");
> 
> where myprotocol:// may, in some situations, return less bytes than
> expected (see the http://php.net/manual/en/class.streamwrapper.php
> wrapper class, stream_read() method). Looking at the implementation of
> this function in ext/standard/image.c, I just found the pattern above.
> If this is really a bug, many other functions might be affected.

Why does your stream behave non-blocking by default? Unless explicitly
stated, those callees probably expect a blocking stream.


-- 
Regards,
Mike

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

Re: [PHP-DEV] [VOTE] [RFC] continue output buffering

[Michael Wallner]

Hi all!

> On 11 03 2015, at 08:26, Matteo Beccati  wrote:
> 
> On 10/03/2015 03:10, Yasuo Ohgaki wrote:
>> Hi Mike,
>> 
>> On Mon, Mar 9, 2015 at 9:45 PM, Michael Wallner  wrote:
>> 
>>> Hi, I’d like to start vote on RFC:continue_ob — any objections?
>>> 
>>> https://wiki.php.net/rfc/continue_ob <https://wiki.php.net/rfc/continue_ob
>>>> 
>>> 
>> 
>> +1
>> I don't mind at all even if you fix this as simple bug fix :)
> 
> I would agree with Yasuo. It seems like a bug fix to me: maybe a RFC is not 
> necessary.

To me, too. But it looked controversial enough to start an RFC instead of a 
commit war.
I think the behaviour pre-5.4 was weird and post-5.4 just of limited use, to 
say the least.

Regards,
Mike


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

[PHP-DEV] [VOTE] [RFC] continue output buffering

[Michael Wallner]

Hi, I’d like to start vote on RFC:continue_ob — any objections?

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

Regards,
Mike

Re: [PHP-DEV] Use behavior thoughts

[Michael Wallner]

> 
> So, I created a PR to remove this error:
> https://github.com/php/php-src/pull/1149 
> 

+1

> 
> Note that there is no BC break here, as it's removing an error condition 
> today.
> 
> This results in a weird edge case (which is 100% valid, but feels odd):
> 
>  class Test {}
> use Bar\Test;
> var_dump(new Test); // class(Bar\Test)
> 
> That's perfectly valid, if not a bit weird.
> 
> The reverse would error mind you:
> 
>  use Bar\Test;
> class Test {}
> 
> Because you've already defined the symbol Test in the file.
> 
> To get around this, I've created another PR with a BC break, adding a
> compile error if code comes before `use`:
> https://github.com/php/php-src/pull/1150

-1, the example you gave looks totally valid.

Regards,
Mike

Re: [PHP-DEV] Consistent function names

[Michael Wallner]

> On 04 03 2015, at 09:58, Lester Caine  wrote:
> 
> On 04/03/15 03:34, Yasuo Ohgaki wrote:
>> 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!
> 
> Taking the starting point ... the coding standard for writing C code for
> PHP ... personally I would love if the PHP code area followed all of the
> rules in the C set. My own particular grip is with using tabs internally
> in the C code, but spaces in the PHP code. The very reason that PSR is
> another inconsistency. So we follow C rules for C code and PSR rules for
> PHP. Or not ... I will always use tabs across all code bases, but the
> other point here is that PSR demands camelCase rather than adding
> underscores and many of the new libraries have been added following that
> format rather than the C rules.
> 
> So even replacing the whole structure of internal names, they will be
> inconsistent with external naming 'rules'. The coding standards
> themselves are inconsistent :(
> 
> If we are looking at the C codespace, then as has already been said we
> are using C library names in a large majority of cases. So programmers
> who are switching between C and PHP codespace either need to rebuild all
> of the C libraries using the new names, or live with that inconsistency?
> 
> I am slowly coming around to the thought that since how I would prefer
> to work is not going to be provided by PHP then creating my own versions
> of some extensions is going to be the right way forward, so I will
> perhaps be working more in 'C' space than in 'PHP' space. This is partly
> because of the growing uncertainty about handling SQL compliant types in
> PHP, and the increasing need to work out how to add back the limit
> checks provided naturally by 32bit processor builds. There are a lot
> more important things than introducing what I view as yet another layer
> of inconsistency when for example, the whole string management area
> needs to be augmented with a proper object based structure where the
> str_ becomes redundant? mbstring should also become redundant in that
> rework.
> 
> As I have already said, the GD library is just a wrapper around the
> underlying libgd C package, and while it is now maintained by Pierre
> under the umbrella of PHP, it is used in other languages so creating a
> new wrapper for PHP without regard for it's C and other interfaces is
> again introducing more inconsistencies.
> 
> While http has been rejected for bundling, it is another example of not
> following the C coding standard …

Lester, please stop posting walls of unrelated text. You’re totally off track. 
If we’re talking about coding standards, we’re not talking about PSR, but 
http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS 


Regards,
Mike

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

[Michael Wallner]

>> Consistency with userland is beneficial, because the majority of PHP
>> developers probably do not expect `new` to yield anything than a
>> concrete instance or an exception.
> 
> Of course, consistency with userland is beneficial. However, in userland
> we do not have many things that we have in internals - like operator
> overloading, function aliasing, etc. - because some of the functionality
> we consider risky and as such better to be left to internals/extensions.
> This is one more example.
> 

None of them cause a fatal error, because it behaves contrary to established 
standards.

>> Quoting php.net/manual:
>> 
>>  To create an instance of a class, the new keyword must be used. An
>> object will *always* be created *unless* the object has a constructor
>> defined that *throws an exception on error*.
> 
> Manual can be fixed.

Everything can be “fixed”, but what’s the right thing to fix? Documentation 
valid for a decade that covers 98% of use cases, which will cause everyone 
to revisit any instance of `new` with internal constructors or rather fix those 
internal classes misbehaving. 

> 
>> Do you know of any other case where a `new` operator in an object
>> oriented context can return NULL, except C++ where you have to
>> explicitly ask for that behavior?
> 
> I can't say I am familiar with every OO language's implementation
> details, so I don't know. But I don't see why, if we think it's useful,
> we can not do it - especially given our factory methods/functions
> already do it. I think it's useful.


That’s okay, but do you think the majority of PHP developers finds that 
undocumented and unexpected behaviour useful?
To me this is as useful as an internal class crashing because it doesn’t 
check if it was instantiated correctly.

Regards,
Mike


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

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

[Michael Wallner]

On 01/03/15 23:05, Stanislav Malyshev wrote:
> Hi!
> 
>> This email is to announce the formal opening of discussion for an RFC
>> to clean up the behaviour of the constructors shown by several
>> internal classes.
>>
>> https://wiki.php.net/rfc/internal_constructor_behaviour
> 
> I'm not sure why this RFC assumes the exception is much better than
> returning null. Exceptions are harder to handle (requires separate
> syntax construct) and they are more expensive at runtime (must create an
> object, collect the backtrace, etc.). Also, not catching the exception
> immediately usually will lead to a complete application failure (usually
> with an obscure error message like "internal operation failed", since
> displaying raw exceptions to the user can be unsafe) instead of
> finer-grained handling.
> It is a long standing tradition in PHP that operations that can be
> expected to fail - like fopen(), date_create(), etc. - do not produce
> fatal errors but instead return error values which can be checked for
> and handled. It is true that some SPL classes departed from that, but
> this IMO was not an improvement but rather an annoyance that each time
> you use an SPL thing you have to write it in a try/catch block. That
> leads to much more boilerplate code than necessary.
> 
> Now I understand that PHP model of doing things may be unusual for some
> people that come from other language background where everything throws
> exceptions for any slightest reason and there's no other means of error
> checking. But I think we can do better rather than that and have more
> flexible error handling - even if it would require people to be
> introduced to a concept they were not familiar with before coming to
> PHP, such as not using exceptions for everything.
> 

I'm not sure I can understand your crusade against this topic.

Consistency with userland is beneficial, because the majority of PHP
developers probably do not expect `new` to yield anything than a
concrete instance or an exception.

Quoting php.net/manual:

To create an instance of a class, the new keyword must be used. An
object will *always* be created *unless* the object has a constructor
defined that *throws an exception on error*.

Emphasis mine.

Do you know of any other case where a `new` operator in an object
oriented context can return NULL, except C++ where you have to
explicitely ask for that behavior?

-- 
Regards,
Mike

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

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

[Michael Wallner]

On 1 Mar 2015 15:56, "Dan Ackroyd"  wrote:
>
> Hi Internals,
>
> This email is to announce the formal opening of discussion for an RFC
> to clean up the behaviour of the constructors shown by several
> internal classes.
>
> https://wiki.php.net/rfc/internal_constructor_behaviour
>
> For reference this was discussed before
> https://marc.info/?l=php-internals&m=142150339323854&w=2

Thank you for proceeding with this RFC.

Re: [PHP-DEV] Re: [RFC][VOTE] pecl_http

[Michael Wallner]

The vote on the pecl_http RFC has been closed, thanks to everyone who 
participated.

The results are 9 in favour and 23 against, so the RFC was declined, which is 
actually an understatement ;)


> On 27 02 2015, at 18:19, Pascal MARTIN, AFUP  wrote:
> 
> 
> Le 26/02/2015 12:28, Michael Wallner a écrit :
>> I forgot to formally declare a voting period, so I’ll do so now.
>> 
>> Voting will end on Feb, 27th at 21:00 UTC, so if you didn’t vote yet, please 
>> do so until then.
>> 
>> https://wiki.php.net/rfc/pecl_http#vote
> 
> Hi,
> 
> Not many of us at AFUP participated in our discussion about this proposal, 
> but it seems we would be on the -1 side.
> 
> Basically, even if a good HTTP layer is a good thing, we feel it kind of has 
> its place more in user-land than in PHP itself.
> 
> Adding this to PHP would mean more maintenance work on PHP itself, but also 
> releases synced with releases of PHP -- which, in the end, is not that 
> interesting for end-users, we think.
> 
> In any case, thanks for your work!
> 
> -- 
> Pascal MARTIN, AFUP - French UG
> http://php-internals.afup.org/
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

[PHP-DEV] Re: [RFC][VOTE] pecl_http

[Michael Wallner]

Hi,

I forgot to formally declare a voting period, so I’ll do so now.

Voting will end on Feb, 27th at 21:00 UTC, so if you didn’t vote yet, please do 
so until then.

https://wiki.php.net/rfc/pecl_http#vote

> On 20 02 2015, at 21:56, Michael Wallner  wrote:
> 
> Hi,
> 
> as already threatened, I hereby open the vote on the pecl_http RFC.
> 
> https://wiki.php.net/rfc/pecl_http#vote
> 
> -- 
> Regards,
> Mike


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

Re: [PHP-DEV] Unnecessary extensions ...

[Michael Wallner]

> On 22 02 2015, at 11:31, Lester Caine  wrote:
> 
> With the discussion on adding http extension by default and not now
> having other key extensions in a normal build I'm looking at what I NEED
> and what I can get away without. On the current PHP7 test build I do not
> have mysqlnd installed as I don't use mysql, but I can't make the mysql
> section available in a second php-fpm instance becuase I can't add
> mysqlnd as a shared module.


Just to clarify that bit: enabling ext/http by default wouldn’t mean it’s not 
possible to disable it.

An extension enabled by default, does not implicitly mean it cannot be 
disabled, like standard or spl.


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

[PHP-DEV] [RFC][VOTE] pecl_http

[Michael Wallner]

Hi,

as already threatened, I hereby open the vote on the pecl_http RFC.

https://wiki.php.net/rfc/pecl_http#vote

-- 
Regards,
Mike

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

[PHP-DEV] [RFC][PRE-VOTE] pecl_http

[Michael Wallner]

Hi!

Please, consider this a warning that I'll put this to vote again shortly.

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

-- 
Regards,
Mike

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

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

[Michael Wallner]

On 19/02/15 13:16, Nikita Nefedov wrote:

> 
> Why not space? It's certainly possible (I just checked) and it would look
> clear I guess:
> 
> my_func(1 999 999);
> 

Yes, but what if I just missed one or two commas there? ;)

-- 
Regards,
Mike

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

[PHP-DEV] [RFC][DISCUSS] Continue output buffering despite aborted connection

[Michael Wallner]

Hi,

I drafted an RFC to continue output buffering despite an aborted
connection was detected.  The title might well be a bit misleading, so
please read the RFC before judgement.

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

-- 
Regards,
Mike

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