PHP 5.6 end of active support

Thank you so much. I can only guess this is posted on a "lifetime" page somewhere on php.net but I didn't see it. Dennis

On 12/14/2016 01:29 PM, David Zuelke wrote:

Actually looking at that bug we see the problem again. This is a Solaris 10 system, which is a very strict POSIX system, but the compiler being used is gcc and the option --std=gnu99 makes reference to a "defacto standard" that exists no where. So this is exactly the problem I see in many many places, code gets releases that compiles with gcc on some systems but will not pass even a basic compile on a strict system with a very tightly conforming compiler such as the Oracle Studio 12.5 tool set. Some code is amazingly clean like libgmp and we also have PHP 5.6.x which compiles with some extensions but the 7.x codebase won't compile. At all. Yet. Very close however.[1] So I need to dig into this as I am sure whatever things I can uncover and perhaps patch will be of benefit across all systems everywhere. I think that is what ( now I am just being pedantic ) standards are all about. Total portability. Dennis [1] discussion happened last month in "[PHP-DEV] C89 vs. C99" thread

<snip>

I have to test with a very strict POSIX system compliant to POSIX.1-2001 and Single UNIX Specification, Version 3 (SUSv3). There is also XNS4 sockets and XTI interfaces which really is XNS5 which is a superset and LP64 clean derivative of XNS4. The XNS4 spec is 32-bit only and I think nearly everything lately is targetted to 64-bit systems specs. Not sure as I am sure there are a bucket of 32-bit embedded systems on the market still with things like Motorola or Freescale system on a chip embedded solutions for automobiles and mobile data access pads. Those are almost always a custom 32-bit Linux kernel for touch screen apps and other control solutions etc etc. However within the strict confines of C99 there is the Oracle Developer Studio which conforms to the ISO/IEC 9899:1999 and ISO/IEC 9899:1990. I think that ISO/IEC 9899:2014 standards compliance is in progress. With some feature test macros we can get access to extensions. From the very long and pedantic man page : If the application is using interfaces and headers not defined by that standard, then in addition to defining the appropriate standard feature test macro, it must also define __EXTENSIONS__. Defining __EXTENSIONS__ provides the application with access to all interfaces and headers not in conflict with the specified standard. The application must define __EXTENSIONS__ either on the compile command line or within the application source files. So the POSIX.1-2001 standards compliance can be enforced with the simple define -D_POSIX_C_SOURCE=200112L but going all the way up to SUSv3 will require -D_XOPEN_SOURCE=600. This is getting a bit off topic but the real idea here is that php 5.6.29 will compile perfectly in a 64-bit strict environment with the allowance for extensions. There is no need to resort to GCC which is not yet in full compliance. PHP 5.6.x then runs its entire testsuite and the results are very positive. This can not ( yet ) be done with PHP 7.x for any value x but I am certainly going to try. OKay .. so the long winded summary is that hoo ray PHP 5.6.x will be around long enough for PHP 7.x to slowly become serious code clean and it may compile within a very strict environment. Dennis