Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97417
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain blastwave.org from 209.17.115.51 cause and error)
To: internals@lists.php.net
References: <cb4383a0-e8ce-160d-d754-4f359ac71d2f@gmx.de>
 <CAJW__o3pTZLh4Zop7FCFyEU1kqLgw2ze2Zg7ZTNo-9WMHNxa4w@mail.gmail.com>
 <ab56a62b-f521-449c-c6a5-169ad859b1e6@blastwave.org>
 <BC.33.21185.4A1B1585@pb1.pair.com>
Message-ID: <bee334ae-a312-50dd-cacd-47cec807c557@blastwave.org>
Date: Wed, 14 Dec 2016 16:31:45 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <BC.33.21185.4A1B1585@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 5.6 end of active support
From: dclarke@blastwave.org (Dennis Clarke)

<snip>
>> Perhaps the gcc compiler is an absolute
>> requirement and if that is true then the code isn't acceptable to any
>> other compiler regardless if it is C99 compliant or otherwise.
>
> GCC is not a requirement. At the very least, PHP compiles on clang and
> MSVC, and I believe it works with some other compilers also.
>

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