Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96864
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Nikita Popov'" <nikita.ppv@gmail.com>,
	"'PHP internals'" <internals@lists.php.net>
References: <d04510ff-0624-c3a4-f53b-9cfe9027dee3@fleshgrinder.com> <CAF+90c-aJL94r4b7S7oKQw3AWbPBO+V_Lctv2JZpHvXnL9c4=Q@mail.gmail.com>
In-Reply-To: <CAF+90c-aJL94r4b7S7oKQw3AWbPBO+V_Lctv2JZpHvXnL9c4=Q@mail.gmail.com>
Date: Sat, 12 Nov 2016 21:18:01 +0100
Message-ID: <0ca001d23d21$e033ec40$a09bc4c0$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIQtcipy2v88QjTT84++ZJcp8nomAJNLz/boEYlMKA=
Content-Language: en-us
Subject: RE: [PHP-DEV] C89 vs. C99
From: anatol.php@belski.net ("Anatol Belski")

Hi Nikita,

> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Saturday, November 12, 2016 11:58 AM
> To: PHP internals <internals@lists.php.net>; Anatol Belski
> <anatol.php@belski.net>
> Subject: Re: [PHP-DEV] C89 vs. C99
>=20
> On Sun, Jun 12, 2016 at 11:08 AM, Fleshgrinder <php@fleshgrinder.com
> <mailto:php@fleshgrinder.com> > wrote:
>=20
>=20
> 	I am curious why we are not finally doing the switch to C99 with VC14
> 	finally supporting most of C99. I mean, I know that GCC and VC14 do =
no
> 	fully support C99 but the most common features are implemented:
>=20
> 	- https://en.wikipedia.org/wiki/C99#Implementations
> <https://en.wikipedia.org/wiki/C99#Implementations>
> 	- https://gcc.gnu.org/c99status.html
> <https://gcc.gnu.org/c99status.html>
>=20
>=20
>=20
> Hi,
>=20
>=20
> It's time to bring this up again. I recently noticed that nowadays =
only Kalle fixes
> Windows build issues due to C99 declarations-after-code, while Anatol =
doesn't.
> Am I correct in the assumption that Anatol is using an MSVC version =
that
> supports the necessary subset of C99, while Kalle uses an older =
version that
> doesn't support this yet? If so, is it viable for us to drop support =
for these older
> MSVC versions for master? I'd really like to be able to use certain =
C99
> functionality (okay, I'm only really interested in declarations mixed =
with code).
>=20
That's a good spot. Indeed, VC++14 implements the C99 features in big =
extent, as announced here

https://msdn.microsoft.com/en-us/library/hh409293.aspx#BK_CRT

VC++11 is only usable with 7.x, because there was no case yet, forcing =
to use a compiler feature that would require VC++14 only. Once this =
moment came, VC11 is out with fire. I use VC11 only for PHP-5.6, as =
that's what we stick to for the standard builds.=20

A less extensive C99 support was already present in VC++12. We produce =
the standard 7.x builds with VC++14, not only for PHP but also for the =
dependency libraries and PECL. Practically, VC++14 is already used for =
over a year, started even with a pre release version, and it only shows =
good results. With C libraries, there was several issues, but they all =
was solvable in favor of VC14. Otherwise, while the old code feels fine =
with the newer compiler, the new horizons open themselves. It was =
already possible, to get some extensions to support Windows build for =
7.0 for this exact reason. Either because the devs didn't care about C89 =
anymore (fe ext/amqp) or because the dependency library expected a C99 =
compiler (fe librdkafka).

In many cases, I haven't checked the exact C99 features libraries use, =
but just went to compile them with VC++14, and there was almost no =
disappointment. Well, it could be, but it's then not related to C99 =
anymore, but more is about some unportable platform features.

Thus, based on my current experiences now over one year, I can tell that =
in regard to VS and C99 features it looks quite optimistic. We de facto =
use C99 compilers nowadays, and we have several cases in the core that =
would profit from this. I can at least recall some cases in math =
functions, but there should be more not necessarily related to the C99 =
specific syntax changes.=20

Regarding the syntax caveats - well, the code esthetics is something =
that we need to agree on. As for me, some cases using inline =
declarations are still useful, fe "for (int k =3D 0, ....);" where the =
scope is guaranteed to be local to the loop. Or the case to partially =
initialize some struct members. Indeed, enabling C99 would mean, the =
course should be in first place to accept the features. We can then =
extend our coding style to make the specific project preferences clear. =
But in general, there is much more than just mixing code and =
declarations or any other syntactic sugar. Take for example the bool and =
other new datatypes, array to pointer conversion, variable lenth arrays, =
comments with // and other even more intrusive features. At some point, =
one might not recognize the PHP source how we know it today, once C99 is =
indeed used in full extent :) C99 indeed is full of other features, but =
the coding style agreement is indeed the only way to solve the esthetic =
issues. And the less we would exclude with the coding style - the easier =
it would be to contribute.=20

IMHO, if we decide to move to C99, we should do it the strict way, =
unlike we do now with C89. VC++ enables C99 the way it can't be turned =
off, but some parts are still missing. In case of GCC and other =
compilers, the -std=3Dc99 should be enforced. A quick check shows, at =
least gcc 4.9.2 with -std=3Dc99 fails to compile PHP. Currently, while =
holding on C89 in general, compilers provide a mess of things like =
partial availability of headers, datatype definitions, etc. If we don't =
do it a strict way, we risk to have even more inconsistent source codes =
following the standard only partially. VC still lacks on some features, =
I'm not sure how strict/complete the C99 implementation in GCC/Clang is. =
Of course, after all, there will be still some compiler dependent =
difference. But in general - enforcing the switch will at least ensure =
the required standard is provided.

Probably, if the work on this should be started, it'd be good to do it =
soon so we're in time with 7.2. For the Windows side - there's currently =
an effort of a new binary tools implementation

https://github.com/OSTC/php-sdk-binary-tools/tree/new_binary_tools

It aims to support newer tools and better operation, but also there's no =
plan to support the environments for compilers older than VC14. If =
everything goes well, and that's actually the plan, the SDK will replace =
the old one for the standard builds. It could be, and actually would =
make sense, to require the new SDK for 7.2, which will automatically =
make VC11 unsupported for it. This would comply well, if a decision to =
require a C99 compiler for the whole project were taken. If we do that, =
we'd better get started soon, so we have enough time for fixes and QA, =
and so the new coding style guide lines can be worked out and agreed. =
And so we have enough time to turn back, if there are unsolvable issues.
=20
Regards

Anatol