Hi Nikita, > -----Original Message----- > From: Nikita Popov [mailto:nikita....@gmail.com] > Sent: Saturday, November 12, 2016 11:58 AM > To: PHP internals <internals@lists.php.net>; Anatol Belski > <anatol....@belski.net> > Subject: Re: [PHP-DEV] C89 vs. C99 > > On Sun, Jun 12, 2016 at 11:08 AM, Fleshgrinder <p...@fleshgrinder.com > <mailto:p...@fleshgrinder.com> > wrote: > > > 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: > > - 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> > > > > Hi, > > > 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). > 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. 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. 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 = 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. 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=c99 should be enforced. A quick check shows, at least gcc 4.9.2 with -std=c99 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. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
