Re: [PHP-DEV] null coalesce addition assignment operator ??+=
On Fri, Jan 19, 2018 at 8:25 PM, Andreas Hennings wrote: > I can definitely say it was not a joke. > Alrighty then... > A: Yeah seems useful, but let's wait (or work) until ??= is > implemented and released, and observe how it is being used. > Funnily enough, ??+= would be easier to implement than ??= because in the case of ??+= we always want to evaluate the RHS, while in the case of ??= the RHS's evaluation is conditional. > B: No one will ever use it, and it would hurt the language. > "hurt" is subjective here, and for every X participants to this thread you'll get X+1 answers on what that means. :p -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
Hi! > I want to see strict typing as an option, not a requirement. You seem to be under impression that this somehow makes things easier. It does not. To explain: let's say you design a strictly typed language, like Java. The compiler knows which variable is of which type at every point, and if it's not clear for some reason, it errors out. You can build a compiler on top of those assumptions. Now let's say you design a loosely typed language, like Javascript. The compiler knows variables have no types, only values have it, and builds on top of that (as in, it doesn't need to implement type tracking for variables). Now, you come in and say - let's make the compiler have *both* assumptions - that sometimes it's strict and sometimes it's not. Sometimes you need to track variable types and sometimes you don't. Sometimes you have type information and can rely on it, and sometimes you don't and have to type-juggle. Do you really think this just made things *easier*? To implement both Java and Javascript inside the same compiler, with radically different types of assumption? If you have desire to answer "yes", then a) please believe me it is not true b) please try to implement a couple of compilers and see how easy it is. Having two options is not even twice as harder as having one. It's much more. So "optional" part adds all work that needs to be done to support strict typing in PHP, and on top of that, you also have to add work that needs to be done to support cases where half of the code is typed and the other half is not. And this is not only code writing work - this is conceptual design work, testing work, documenting work, etc. Without even going to the merits of the proposal itself, it certainly looks to me like you are seriously underestimating what we're talking about, complexity-wise. I am not saying it's not possible at all - a lot of things are possible. It's just "it's merely an option" is exactly the wrong position to take. > Create a symbol table that holds the strict variables and the types they > are locked into. The strict keyword pushes them onto that table, the var > keyword pulls them off. When an operation that cares about type occurs > check that table - if the var appears there than authenticate it. And now every function and code piece that works with symbol tables needs to be modified to account for the fact that there are two of them. Every lookup is now two lookups, and no idea how $$var would even work at all. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] v7.2.1 test cases crash on s390x
Hi, When testing v7.2.1 on s390x two cases are found crash: 1) ext/mbstring/tests/mb_ereg.phpt ; 2) ext/mbstring/tests/mb_ereg_variation5.phpt] ; It happens at /home/work/php/php/ext/mbstring/oniguruma/src/regexec.c:2481, here is the code (replaced the macros): 2474case OP_STATE_CHECK_PUSH: MOP_IN(OP_STATE_CHECK_PUSH); 2475 GET_STATE_CHECK_NUM_INC(mem, p); 2476// STATE_CHECK_VAL(scv, mem); 2477 do { 2478 if (state_check_buff != NULL) { 2479//int x = STATE_CHECK_POS(s,mem); 2480int x = (((s) - str) * num_comb_exp_check + ((mem) - 1)); 2481(scv) = state_check_buff[x/8] & (1<<(x%8)); 2482 } 2483 else (scv) = 0; 2484} while(0); 2485 (gdb) p x $1 = 196680 (gdb) p x/8 $2 = 24585 However the array "state_check_buff" index is 0--20311. "mem" is come from the macro "GET_STATE_CHECK_NUM_INC", which refers to "StateCheckNumType", Here is the definition of StateCheckNumType: in ext/mbstring/oniguruma/src/regint.h ... 530 typedef int MemNumType; 531 typedef short int StateCheckNumType; 532 typedef void* PointerType; ... Not understanding why StateCheckNumType is defined as short int, but others are all int. If change it as "int", two crashes are gone and 5 cases related to "mb_ereg() " are passed. Testing on x86_64 show 5 cases are alos passed (same as before). Thanks, Sam
Re: [PHP-DEV] [RFC] is_countable
On Mon, Jan 22, 2018 at 5:34 AM, Johannes Schlüter wrote: > Hi, > > On So, 2018-01-21 at 18:01 +, Gabriel Caruso wrote: >> After that, I like to propose and discuss a new function for PHP 7.x >> (current 7.3): is_countable. >> >> *RFC*: https://wiki.php.net/rfc/is-countable. > > The primary place for this imo should be reflection. You did not provide any justification. As you do so keep in mind a lot of code is going to look like: if (is_countable($arg)) { /* take a different code path, such as pre-allocating storage */ } This is not an easily reflectable thing because it's based on an argument which may not even be an object type. Additionally we have a well-established convention of `is_*` function for types specifically known to the engine as is the case here. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] is_countable
Hi Johannes, thanks for your feedback! Can I ask you to elaborate (or maybe share a link where can I study and improve) more about the Reflection part? Sorry if it’s sounds trivial, is because I’m new to internals 😄 Em seg, 22 de jan de 2018 às 10:34, Johannes Schlüter < johan...@schlueters.de> escreveu: > Hi, > > On So, 2018-01-21 at 18:01 +, Gabriel Caruso wrote: > > After that, I like to propose and discuss a new function for PHP 7.x > > (current 7.3): is_countable. > > > > *RFC*: https://wiki.php.net/rfc/is-countable. > > The primary place for this imo should be reflection. If there is high > demand we could also add a shortcut function like proposed (no strong > opinion on this either way from my side) > > Of course I notice that the current reflection can't cover all the > cases you want to cover, so maybe it might be interesting to extend > reflection with something which works on all variables/zval and wraps > all the is_* functions. > > johannes > > -- Gabriel Caruso
Re: [PHP-DEV] PCNTL compatibility to Windows?
Wow! Thanks for this very detailed anwser! I really could not understand everything because of my limitation about this topic, but I really could understand the reasons that it will not works fine and I agree that, for now, it is not a good idea (because of hackish way to implement it, mainly). Thank you! 2018-01-22 13:58 GMT-02:00 Thomas Hruska : > On 1/22/2018 5:16 AM, David Rodrigues wrote: > >> Hello. >> >> I know that PCNTL extension is not compatible with Windows, but I can't >> found the reason for that. >> >> I mean, I know that it is a feature that Unix system could provide in a >> better way (natively I guess). But "why" Windows could not emulates this >> features and have a PCNTL support too? Even if it had a lower performance, >> it still could be useful on testing environments. >> >> So the question is: there are some hard limitation to it be impossible or >> would it be kind of a "lack of interest"? >> >> Thanks! >> > > Windows is a completely different OS. > > > Windows does not have signals: > > https://stackoverflow.com/questions/276/signal-handling-on-windows > > That rules out all of PCNTL's signal handling support, which is 11 out of > the 22 functions that PCNTL has (I'm excluding aliases in that count). > Simply being unable to implement 50% of the functions is not a good start > to a successful port. > > > Windows does not have fork/exec. Although there are non-starter > "solutions": > > https://en.wikipedia.org/wiki/Fork%E2%80%93exec > > Windows starts and manages processes VERY differently from *NIX. Cygwin > apparently has a working fork/exec implementation for Windows, but Cygwin > is GPL. Any implementation would have to be clean-roomed for PHP and would > likely involve ugly things such as copying raw memory from one process > space to another and/or using undocumented Zw kernel calls, all of which > can change dramatically between OS releases. > > > Windows processes are referenced by HANDLE, not process ID. Referencing > by process ID might seem doable with OpenProcess(): > > https://msdn.microsoft.com/en-us/library/windows/desktop/ms6 > 84320(v=vs.85).aspx > > But even PROCESS_QUERY_LIMITED_INFORMATION access might be denied when > attempting to open the handle. Even for child processes. It happens when > a process changes its own DACLs specifically to block > OpenProcess()/OpenThread() calls. Although the approach can't readily > block SeDebugPrivilege, you don't ever want PHP core/userland running with > SeDebugPrivilege. > > A PHP implementation might work fine for direct children for most > use-cases where the HANDLEs are kept around, but grandchildren might not be > accessible. Also, there's already the "proc_..." series of functions for > handling child processes, which more correctly uses generic resource > handles instead of integers. > > > Windows does not know what a zombie process is. Unlike *NIX, Windows > doesn't have a rule that a child must have a parent and that the parent > must wait on each child to exit before the parent itself exits. Windows > processes can exit whenever they want and the kernel cleans up after the > process. > > > Windows does have a few process priorities: > > https://msdn.microsoft.com/en-us/library/windows/desktop/ms6 > 86219(v=vs.85).aspx > > However, you can do things such as completely freeze up Windows - > including the keyboard processing buffer and mouse cursor - with a process > priority of REALTIME_PRIORITY_CLASS and a "while (1)" loop where the > specified process will get *exclusive* scheduling by the kernel (i.e. a > reboot is the only option). It's a little-known security > vulnerability-waiting-to-happen bit of Windows API history. > > > I dunno. When all is said and done, pcntl_getpriority(), > pcntl_setpriority(), pcntl_get_last_error(), pcntl_strerror(), and maybe > pcntl_wait() and associated status functions are about the only functions > that can be somewhat cleanly implemented for Windows using Windows APIs > with minimal effort. pcntl_waitpid() might be able to be implemented with > some effort but possibly not work properly for pids less than 1 (with all > the usual waitpid() caveats). The signal handling are simply not doable. > Implementing fork/exec doesn't make a lot of sense - a lot of effort for > little gain. > > -- > Thomas Hruska > CubicleSoft President > > I've got great, time saving software that you will find useful. > > http://cubiclesoft.com/ > > And once you find my software useful: > > http://cubiclesoft.com/donate/ > -- David Rodrigues
Re: [PHP-DEV] PCNTL compatibility to Windows?
On 1/22/2018 5:16 AM, David Rodrigues wrote: Hello. I know that PCNTL extension is not compatible with Windows, but I can't found the reason for that. I mean, I know that it is a feature that Unix system could provide in a better way (natively I guess). But "why" Windows could not emulates this features and have a PCNTL support too? Even if it had a lower performance, it still could be useful on testing environments. So the question is: there are some hard limitation to it be impossible or would it be kind of a "lack of interest"? Thanks! Windows is a completely different OS. Windows does not have signals: https://stackoverflow.com/questions/276/signal-handling-on-windows That rules out all of PCNTL's signal handling support, which is 11 out of the 22 functions that PCNTL has (I'm excluding aliases in that count). Simply being unable to implement 50% of the functions is not a good start to a successful port. Windows does not have fork/exec. Although there are non-starter "solutions": https://en.wikipedia.org/wiki/Fork%E2%80%93exec Windows starts and manages processes VERY differently from *NIX. Cygwin apparently has a working fork/exec implementation for Windows, but Cygwin is GPL. Any implementation would have to be clean-roomed for PHP and would likely involve ugly things such as copying raw memory from one process space to another and/or using undocumented Zw kernel calls, all of which can change dramatically between OS releases. Windows processes are referenced by HANDLE, not process ID. Referencing by process ID might seem doable with OpenProcess(): https://msdn.microsoft.com/en-us/library/windows/desktop/ms684320(v=vs.85).aspx But even PROCESS_QUERY_LIMITED_INFORMATION access might be denied when attempting to open the handle. Even for child processes. It happens when a process changes its own DACLs specifically to block OpenProcess()/OpenThread() calls. Although the approach can't readily block SeDebugPrivilege, you don't ever want PHP core/userland running with SeDebugPrivilege. A PHP implementation might work fine for direct children for most use-cases where the HANDLEs are kept around, but grandchildren might not be accessible. Also, there's already the "proc_..." series of functions for handling child processes, which more correctly uses generic resource handles instead of integers. Windows does not know what a zombie process is. Unlike *NIX, Windows doesn't have a rule that a child must have a parent and that the parent must wait on each child to exit before the parent itself exits. Windows processes can exit whenever they want and the kernel cleans up after the process. Windows does have a few process priorities: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686219(v=vs.85).aspx However, you can do things such as completely freeze up Windows - including the keyboard processing buffer and mouse cursor - with a process priority of REALTIME_PRIORITY_CLASS and a "while (1)" loop where the specified process will get *exclusive* scheduling by the kernel (i.e. a reboot is the only option). It's a little-known security vulnerability-waiting-to-happen bit of Windows API history. I dunno. When all is said and done, pcntl_getpriority(), pcntl_setpriority(), pcntl_get_last_error(), pcntl_strerror(), and maybe pcntl_wait() and associated status functions are about the only functions that can be somewhat cleanly implemented for Windows using Windows APIs with minimal effort. pcntl_waitpid() might be able to be implemented with some effort but possibly not work properly for pids less than 1 (with all the usual waitpid() caveats). The signal handling are simply not doable. Implementing fork/exec doesn't make a lot of sense - a lot of effort for little gain. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Big_Endian problem
Thank Sara. Yes, on s390x, it is broken. The function "ignore_user_abort" returns "256" on s390x, and "1" on x86_64 after "ignore_user_abort" is set to true; Please let me know when you finished code changes on v7.2.1. I will test on s390x. Thanks, Sam p...@golemon.com wrote on 01/19/2018 05:07:25 PM: > From: Sara Golemon > To: Sam Ding > Cc: PHP internals > Date: 01/19/2018 05:07 PM > Subject: Re: [PHP-DEV] Big_Endian problem > Sent by: p...@golemon.com > > On Fri, Jan 19, 2018 at 4:04 PM, Sam Ding wrote: > > The test case ext/standard/tests/general_functions/bug72300.phpt is failed > > on s390x. > > The function "ignore_user_abort" returns "256" on s390x, and "1" on x86_64 > > after "ignore_user_abort" is set to true; > > The root reason is because of Big_Endian on s390x. > > Here is the C code: ext/standard/basic_functions.c > > b/ext/standard/basic_functions.c:5641 > > > >old_setting = (unsigned short)PG(ignore_user_abort); > > //php_core_globals.ignore_user_abort, "x /2b" shows its > > value : "0x01 0x00" on both platforms > > > That specific line isn't the problem, as it's just cashing a short to > an unsigned short, which is legal and not problematic for any > endianness. > > The actual problem is that PG(ignore_user_abort) is declared as a > short, but its INI handler method is defined as OnUpdateBool (which of > course, only operates on a single byte). > > > Does PHP interpreter support Big_Endian? Are there any existing > > macros/functions to deal with Big/Little Endian? > > > Yep. And if things break on s390x, please let us know! > > I'll put together a fix for this over the weekend and apply it to 7.0 > and later versions. > > -Sara >
Re: [PHP-DEV] [RFC] is_countable
Hi, On So, 2018-01-21 at 18:01 +, Gabriel Caruso wrote: > After that, I like to propose and discuss a new function for PHP 7.x > (current 7.3): is_countable. > > *RFC*: https://wiki.php.net/rfc/is-countable. The primary place for this imo should be reflection. If there is high demand we could also add a shortcut function like proposed (no strong opinion on this either way from my side) Of course I notice that the current reflection can't cover all the cases you want to cover, so maybe it might be interesting to extend reflection with something which works on all variables/zval and wraps all the is_* functions. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PCNTL compatibility to Windows?
Hello. I know that PCNTL extension is not compatible with Windows, but I can't found the reason for that. I mean, I know that it is a feature that Unix system could provide in a better way (natively I guess). But "why" Windows could not emulates this features and have a PCNTL support too? Even if it had a lower performance, it still could be useful on testing environments. So the question is: there are some hard limitation to it be impossible or would it be kind of a "lack of interest"? Thanks! -- David Rodrigues
Re: [PHP-DEV] [RFC] is_countable
Hi Gabriel, I proposed a similar function at the time of introducing the warning, but it doesn't look like I got around to creating an RFC for it: https://github.com/php/php-src/pull/2206/files During this work we realised that objects don't have to implement the '\Countable' interface to be successfully handled by 'count()', internal/extension classes can implement a 'count_elements' handler and ignore the interface. I'd suggest that 'is_countable()' should be consistent with 'count()'. Thanks, Craig