# Require C11 in PHP 8.4 - Thread: https://externals.io/message/124706 - Original archive: https://news-web.php.net/php.internals/124706 - Started by Ilija Tovilo on 2024-08-01T21:57:36+00:00 - Messages: 33 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/124706.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #124706 — Ilija Tovilo — 2024-08-01T21:57:36+00:00 URL: https://externals.io/message/124706#124706 Hi everyone We've gotten a bug report about compile errors in the PHP 8.4 alpha on old C99 compilers (and on some modern compilers when passing the -std=c99 flag). Specifically, C99 does not support typedef redeclarations, which is a C11 feature. ```c // some_header.h typedef struct _zval_struct zval; void some_func(zval *zv); // zend_types.h struct _zval_struct { ... }; typedef struct _zval_struct zval; ``` Some headers might want to forward declare zval so that zend_types.h doesn't have to be included. The two primary reasons you might want to avoid that are 1. to reduce compile times if the header is very large and 2. to prevent recursive header dependencies. However, in C99 this code is actually illegal if both of these headers end up being included, because redeclarations of typedefs are not allowed. To fix it, the typedef must be removed and the signatures must refer to the struct directly. ```c // some_header.h struct _zval_struct; void some_func(struct _zval_struct *zv); ``` I started fixing these in a PR [1] which required more changes than expected. After a short discourse, we were wondering whether it might be better to switch to a newer C standard instead. Our coding standards [2] currently specify that compiling php-src requires C99. The Unix installation page on php.net [3] claims it is ANSI C, which is certainly outdated. There have been suggestions to require C11 for a while, which should be well supported by all compilers shipped with maintained distributions. GCC gained support for C11 in 4.7 [4], LLVM Clang in 3.1, both released in 2012. For context, Debian Bullseye comes with GCC 10.2 [5], Ubuntu Focal Fossa comes with GCC 9.3 [6], RHEL 8 comes with GCC 8.x [7]. The biggest blocker in the past was MSVC, which has finally added C11 support in Visual Studio 2019 [8]. Technically, Visual Studio 2015 and 2017 are still supported by Microsoft [9], but according to Christoph they are no longer used for PHP builds since version 8. Hence, it seems like it would be ok to bump our C compiler requirement to C11. We'd like to make this change before beta 1 if there are no objections. There are no immediate plans to make non-optional use of other C11 features, although that is conceivable at some point. Another benefit brought up by Christoph is that C11 relegated the requirement for the compiler to support VLAs (variable-length arrays) which was never implemented by MSVC, technically not complying with the currently required standard. If you do have any concerns, please let me know. Ilija [1] https://github.com/php/php-src/pull/15079 [2] [https://github.com/php/php-src/blob/8b6f14a9a221599b076e4bc3570f013a7e65aa21/CODING_STANDARDS.md?plain=1#L12](https://github.com/php/php-src/blob/8b6f14a9a221599b076e4bc3570f013a7e65aa21/CODING_STANDARDS.md?plain=1#L12) [3] https://www.php.net/manual/en/install.unix.php [4] https://stackoverflow.com/a/16256596 [5] https://packages.debian.org/bullseye/gcc [6] https://packages.ubuntu.com/focal/gcc [7] https://access.redhat.com/solutions/19458 [8] https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ [9] https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing --- ## #124707 — Derick Rethans — 2024-08-01T22:26:10+00:00 URL: https://externals.io/message/124706#124707 · In reply to: #124706 >Hi everyone > >We've gotten a bug report about compile errors in the PHP 8.4 alpha on >old C99 compilers (and on some modern compilers when passing the >-std=c99 flag). Specifically, C99 does not support typedef >redeclarations, which is a C11 feature. > >```c >// some_header.h >typedef struct _zval_struct zval; >void some_func(zval *zv); > >// zend_types.h >struct _zval_struct { ... }; >typedef struct _zval_struct zval; >``` > >Some headers might want to forward declare zval so that zend_types.h >doesn't have to be included. The two primary reasons you might want to >avoid that are 1. to reduce compile times if the header is very large >and 2. to prevent recursive header dependencies. > >However, in C99 this code is actually illegal if both of these headers >end up being included, because redeclarations of typedefs are not >allowed. To fix it, the typedef must be removed and the signatures >must refer to the struct directly. > >```c >// some_header.h >struct _zval_struct; >void some_func(struct _zval_struct *zv); >``` > >I started fixing these in a PR [1] which required more changes than >expected. After a short discourse, we were wondering whether it might >be better to switch to a newer C standard instead. Our coding >standards [2] currently specify that compiling php-src requires C99. >The Unix installation page on php.net [3] claims it is ANSI C, which >is certainly outdated. There have been suggestions to require C11 for >a while, which should be well supported by all compilers shipped with >maintained distributions. > >GCC gained support for C11 in 4.7 [4], LLVM Clang in 3.1, both >released in 2012. For context, Debian Bullseye comes with GCC 10.2 >[5], Ubuntu Focal Fossa comes with GCC 9.3 [6], RHEL 8 comes with GCC >8.x [7]. Even Debian wheezy (out of extended LTS support) or Ubuntu 14.04 have GCC 4.7, so that seems OK. How about Clang (for OSX) though? I can't check that easily. cheers Derick --- ## #124710 — Stephen Reay — 2024-08-02T05:50:30+00:00 URL: https://externals.io/message/124706#124710 · In reply to: #124707 > > > > > […] > > Even Debian wheezy (out of extended LTS support) or Ubuntu 14.04 have GCC 4.7, so that seems OK. > > How about Clang (for OSX) though? I can't check that easily. > > cheers > Derick Hi, According to https://releases.llvm.org/3.1/docs/ClangReleaseNotes.html#cchanges, Clang 3.1 added C11. According to https://trac.macports.org/wiki/XcodeVersionInfo, Clang 3.1 shipped with Xcode 4.3.3, in May 2012. In terms of confirming this, the oldest macOS VM I have quick access to is running Sierra (from 2016, last OS update in 2019), and default install now for Clang on that VM is 9.0.0 Hope this helps Cheers Stephen --- ## #124712 — Christoph M. Becker — 2024-08-02T09:54:16+00:00 URL: https://externals.io/message/124706#124712 · In reply to: #124710 > According to https://releases.llvm.org/3.1/docs/ClangReleaseNotes.html#cchanges, Clang 3.1 added C11. > > According to https://trac.macports.org/wiki/XcodeVersionInfo, Clang 3.1 shipped with Xcode 4.3.3, in May 2012. > > In terms of confirming this, the oldest macOS VM I have quick access to is running Sierra (from 2016, last OS update in 2019), and default install now for Clang on that VM is 9.0.0 According to a comment on the pull request[1], the clang version would be different between LLVM and Apple's fork. An answer on StackOverflow[2] confirms that. I figure that there is even no exact matching of the version numbers possible, as Apple might support some features, but not others. I can even imagine that general C11 support is available, but not necessarily the typedef redeclaration which is most important right now. So unless there is some normative documentation, it might be necessary to see whether PHP 8.4 can be build with Apple's clang (and which versions). [1] [2] Cheers, Christoph --- ## #124713 — Christoph M. Becker — 2024-08-02T10:32:01+00:00 URL: https://externals.io/message/124706#124713 · In reply to: #124706 > […] The biggest blocker in the past was MSVC, which has finally > added C11 support in Visual Studio 2019 [8]. Technically, Visual > Studio 2015 and 2017 are still supported by Microsoft [9], but > according to Christoph they are no longer used for PHP builds since > version 8. Right. As of PHP 8.0.0, VS16 (aka. Visual Studio 2019) is used for the builds, and as of PHP 8.4.0, VS17 (aka. Visual Studio 2022) is supposed to be used. Of course, users may still use an older Visual Studio version, and want to be able to still build latest PHP, but they still can install a newer Visual Studio version in parallel (and at least, using only the Buildtools for Visual Studio 2022, shouldn't be a concern regarding the license, because they are free to use to build Open-Source software, and should be totally sufficient to build PHP and extensions). There might be a slight glitch, namely that a few users want to include some PHP modules into their software (e.g. the embed SAPI); that might cause issues, but on the other hand, nobody should expect to work some latest Open-Source software version to work flawlessly with older versions of other software. So these users (if there are any) could still work with PHP 8.3, for instance, until they upgrade to Visual Studio 2022. > Hence, it seems like it would be ok to bump our C compiler requirement > to C11. We'd like to make this change before beta 1 if there are no > objections. There are no immediate plans to make non-optional use of > other C11 features, although that is conceivable at some point. I'm all for it, given the alternatives would be worse, and presuming there is no real show-stopper. > Another benefit brought up by Christoph is that C11 relegated the > requirement for the compiler to support VLAs (variable-length arrays) > which was never implemented by MSVC, technically not complying with > the currently required standard. Indeed, that caused a couple of issues in the past, not only for php-src, but also for extensions. Requiring C11 support might help developers to detect that early, and choose an alternative implementation right away. > [8] https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ > [9] https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing Cheers, Christoph --- ## #124716 — Giovanni Giacobbi — 2024-08-02T12:33:53+00:00 URL: https://externals.io/message/124706#124716 · In reply to: #124706 > [...] > I started fixing these in a PR [1] which required more changes than > expected. After a short discourse, we were wondering whether it might > be better to switch to a newer C standard instead. Our coding > standards [2] currently specify that compiling php-src requires C99. > The Unix installation page on php.net [3] claims it is ANSI C, which > is certainly outdated. There have been suggestions to require C11 for > a while, which should be well supported by all compilers shipped with > maintained distributions. > It feels wrong to raise such an important requirement that might affect a lot of people, including maintainers of extensions, for just one specific problem, and 99% of the codebase would still be C99 compliant. I quickly put together an alternative PR (#15202) with a slightly different approach, just as a proof of concept. The idea is to move all the global typedefs in a new include header "zend_types_defs.h" (but also zend_portability.h can be reused for this purpose, as all the relevant files already include it). While putting together that PR, I had the feeling that this typedef redefinition problem is in reality hiding some smelly design of header files. So maybe, rather than requiring a compiler more tolerant to poor code, we should rather focus on getting the design right. --- ## #124717 — Jakub Zelenka — 2024-08-02T14:20:59+00:00 URL: https://externals.io/message/124706#124717 · In reply to: #124716 Hi, On Fri, Aug 2, 2024 at 1:36 PM Giovanni Giacobbi wrote: > It feels wrong to raise such an important requirement that might affect a > lot of people, including maintainers of extensions > Why do you think that this might affect a lot of people? We are talking about minimum GCC version 4.7 and really old Clang version (that probably no one uses) as well. And minimum MSVC is already 2019. Do you know about some specific platforms that would be affected by this? Cheers Jakub --- ## #124739 — Gina P. Banyard — 2024-08-04T16:01:43+00:00 URL: https://externals.io/message/124706#124739 · In reply to: #124716 > > > > […] > > It feels wrong to raise such an important requirement that might affect a lot of people, including maintainers of extensions, for just one specific problem, and 99% of the codebase would still be C99 compliant. > > I quickly put together an alternative PR (#15202) with a slightly different approach, just as a proof of concept. The idea is to move all the global typedefs in a new include header "zend_types_defs.h" (but also zend_portability.h can be reused for this purpose, as all the relevant files already include it). > > While putting together that PR, I had the feeling that this typedef redefinition problem is in reality hiding some smelly design of header files. So maybe, rather than requiring a compiler more tolerant to poor code, we should rather focus on getting the design right. I would like to see actual factual data rather than "vibes" as to how this would cause issues with third-party extensions. php-src is not C99 pedeantic compliant and we do use GCC extenstions. I do agree that maybe we should go back to fixing headers, but considering the drama this caused 18 months ago I do not know who here has the motivation to do this. Ideally I feel we should target C17 as it is a "bug fix" release of C11, but this might be impossible due to old compilers still being the default on LTS Distributions. The main benefit of C11/17 in the long run are atomics, that we kinda use already anyway. Moreover, as someone that has written an extension that has some usage, when I go back to it, I'd rather like to be able to use features from C23 than be stuck on C99, but that is just me. Best regards, Gina P. Banyard --- ## #124755 — Derick Rethans — 2024-08-05T10:49:22+00:00 URL: https://externals.io/message/124706#124755 · In reply to: #124706 > Hence, it seems like it would be ok to bump our C compiler requirement > to C11. We'd like to make this change before beta 1 if there are no > objections. How would you enforce that, through configure? FWIW, I have just tried compiling Xdebug with -std=c2x (C23) and that caused me one trivial required change: https://github.com/xdebug/xdebug/pull/969/files cheers, Derick --- ## #124760 — Christoph M. Becker — 2024-08-05T11:37:44+00:00 URL: https://externals.io/message/124706#124760 · In reply to: #124755 > > > > […] > > How would you enforce that, through configure? In my opinion, there is no *need* to enforce this requirement. Just having documentation should be sufficient. Users with an old compilerr will notice issues (i.e. build failures), and even if they don't care to look up the docs, they will file a ticket, and that can quickly be closed pointing to the relevant documentation. Christoph --- ## #124769 — Derick Rethans — 2024-08-05T14:59:58+00:00 URL: https://externals.io/message/124706#124769 · In reply to: #124760 > > > > […] > > In my opinion, there is no *need* to enforce this requirement. Just > having documentation should be sufficient. Users with an old > compilerr will notice issues (i.e. build failures), and even if they > don't care to look up the docs, they will file a ticket, and that can > quickly be closed pointing to the relevant documentation. Instead of having to deal with tickets, wouldn't be be easier if the compiler they used works with the features that we are using? That could instantly provide a link to the documentation saving all of us time. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social --- ## #124772 — Pierre Joye — 2024-08-05T15:42:50+00:00 URL: https://externals.io/message/124706#124772 · In reply to: #124769 > Instead of having to deal with tickets, wouldn't be be easier if the > compiler they used works with the features that we are using? That could > instantly provide a link to the documentation saving all of us time. > it is significantly easier at configure time. Gcc 4.9 is (almost) fully c11 compliant (not 4.7). As of windows, it will be dependent on the vc version used by the php minor branch where it may be introduced. That being said, I am not sure if the reason mentioned for using c11 in the initial post is used in external extensions (included headers etc), but at least on linux (or similar), an ext can be compiled with any version. On windows, we can't, mainly for memory management issues (alloc/realloc or freed using different crt). It is possible but too many extensions, also in core, cause issues. best, Pierre --- ## #124775 — Christoph M. Becker — 2024-08-05T16:27:22+00:00 URL: https://externals.io/message/124706#124775 · In reply to: #124769 > > > > […] > > Instead of having to deal with tickets, wouldn't be be easier if the > compiler they used works with the features that we are using? That could > instantly provide a link to the documentation saving all of us time. Note that I'm not *against* checking C11 support during configure. If there is a respective feature test readily available for autoconf – great. Otherwise it might be sufficient to check for the definition and value of __STDC_VERSION__. However, I don't think it would be a good idea to test for certain compilers and their versions; that list might need more maintaince than catering to a couple of bug reports. Before we go down that route, we may be better off just documenting the requirement. Christoph --- ## #124776 — Levi Morrison — 2024-08-05T16:42:38+00:00 URL: https://externals.io/message/124706#124776 · In reply to: #124739 > > > > > > > […] > > > It feels wrong to raise such an important requirement that might affect a lot of people, including maintainers of extensions, for just one specific problem, and 99% of the codebase would still be C99 compliant. > > I quickly put together an alternative PR (#15202) with a slightly different approach, just as a proof of concept. The idea is to move all the global typedefs in a new include header "zend_types_defs.h" (but also zend_portability.h can be reused for this purpose, as all the relevant files already include it). > > While putting together that PR, I had the feeling that this typedef redefinition problem is in reality hiding some smelly design of header files. So maybe, rather than requiring a compiler more tolerant to poor code, we should rather focus on getting the design right. > > > I would like to see actual factual data rather than "vibes" as to how this would cause issues with third-party extensions. > php-src is not C99 pedeantic compliant and we do use GCC extenstions. > > I do agree that maybe we should go back to fixing headers, but considering the drama this caused 18 months ago I do not know who here has the motivation to do this. > > Ideally I feel we should target C17 as it is a "bug fix" release of C11, but this might be impossible due to old compilers still being the default on LTS Distributions. > The main benefit of C11/17 in the long run are atomics, that we kinda use already anyway. As a person who wrote some of those atomics, I would definitely prefer to move to standard C11/C17 atomics at some point in the future and remove all other fallbacks. The blocker right now is Microsoft Visual Studio. Although they added C11/C17 support a few versions back, they did not add atomics at that time. It's available now, but it is still experimental as far as I can tell. Maybe for PHP 9.0 we can address header issues and also by then VS will have a general release we can move to for atomics. One thing I feel strongly about is that we should not add flags like `-std=c11`. If we check, we ought to just ensure that whatever flags the user provided, we have certain C11/C17 features. This allows for extensions to use a newer version, or a relaxed version like `-std=gnu11`. --- ## #124781 — Christoph M. Becker — 2024-08-05T17:10:57+00:00 URL: https://externals.io/message/124706#124781 · In reply to: #124772 > > > > […] > > it is significantly easier at configure time. Gcc 4.9 is (almost) fully c11 > compliant (not 4.7). But what about other compilers we support on non Windows platforms currently, like clang, Apple's clang, Solaris Studio and maybe some more we don't even know about. > As of windows, it will be dependent on the vc version used by the php minor > branch where it may be introduced. It's supposed to be introduced as of PHP 8.4.0, which already uses VS 17, although MSVC supports C11 as of VS 16.5 (while it never claimed to support C99). So in practise, even those still building their own Windows binaries with Visual Studio 2019 should not be affected. > That being said, I am not sure if the reason mentioned for using c11 in the > initial post is used in external extensions (included headers etc), but at > least on linux (or similar), an ext can be compiled with any version. I somewhat doubt that; we're using a couple of C99 features (like mixed declarations and statements) in the core for a couple of years (IIRC, as of PHP 8.0.0), and extensions may do this with their own code, or might be forced to include public php-src headers which may use some C99 features. This may not be an issue with any C compilers actually still in use, but can be sure about that? And some extensions even require C++ support. Christoph --- ## #124801 — Christoph M. Becker — 2024-08-06T11:04:31+00:00 URL: https://externals.io/message/124706#124801 · In reply to: #124776 > As a person who wrote some of those atomics, I would definitely prefer > to move to standard C11/C17 atomics at some point in the future and > remove all other fallbacks. The blocker right now is Microsoft Visual > Studio. Although they added C11/C17 support a few versions back, they > did not add atomics at that time. It's available now, but it is still > experimental as far as I can tell. There is a MS blog post from December, 2022[1] which claims that it is experimental, and that you would need to specify the /experimental:c11atomics flag in addition to /std:c11 to enable atomics support. I though, hey, why not try that out, added only /std:c11 and got a failing minimal build, because apparently max_align_t is not defined in stddef.h even with the latest available SDK (10.0.26100.0) offered by Visual Studio 2022 for my Windows 10 machine. It might be available with SDK 10.0.22621.2428, which according to the documentation[2] has been "Relesed in October 2024"[sic]. I wonder whether I would trust more detailed information there. (FWIW, the official Windows builds use 10.0.22621.0, and we probably should enforce some common version; I think for now we use just what can be found in the build environment.) Anyway, I worked around the missing max_align_t definition, and the build succeeded, even though I've added #ifndef __STDC_NO_ATOMICS__ # error cmb #endif in zend_API.c. Thus, I conclude that atomics support in latest Visual Studio 17.10.5 is no longer deemed experimental, and locking atomics are implemented now. I think it is worth investigating whether that support actually works for our purposes, but probably not use that for PHP 8.4. [1] [2] Christoph --- ## #124802 — Derick Rethans — 2024-08-06T11:26:02+00:00 URL: https://externals.io/message/124706#124802 · In reply to: #124781 > > > > […] > > But what about other compilers we support on non Windows platforms > currently, like clang, Apple's clang, Solaris Studio and maybe some > more we don't even know about. Normal clang supports the same flag. Apple clang potentially too, but not currently: https://opensource.apple.com/source/clang/clang-23/clang/tools/clang/docs/UsersManual.html — it could be outdated information though. I don't have a mac to test. But it's just possible to check for the flag for compilers that we *do* know about. And by checking for it and showing a warning, we make people's lives easire. cheers, Derick --- ## #124803 — Christoph M. Becker — 2024-08-06T12:00:32+00:00 URL: https://externals.io/message/124706#124803 · In reply to: #124802 > Normal clang supports the same flag. Apple clang potentially too, but > not currently: > https://opensource.apple.com/source/clang/clang-23/clang/tools/clang/docs/UsersManual.html > — it could be outdated information though. I don't have a mac to test. > > But it's just possible to check for the flag for compilers that we *do* > know about. And by checking for it and showing a warning, we make > people's lives easire. Not sure about which flag you are talking, but anyway see . I.e. I'm fine with a feature test, but wouldn't want to check for individual compiler versions (although I have no hard feelings about that). Christoph --- ## #124804 — Stephen Reay — 2024-08-06T12:07:54+00:00 URL: https://externals.io/message/124706#124804 · In reply to: #124802 > > > Normal clang supports the same flag. Apple clang potentially too, but > not currently: > https://opensource.apple.com/source/clang/clang-23/clang/tools/clang/docs/UsersManual.html > — it could be outdated information though. I don't have a mac to test. > I believe that is *extrmely* outdated, based on the other listings on https://opensource.apple.com/source/clang/ and the listings by macOS version on https://opensource.apple.com/releases/ To be certain, I fired up my old macOS Sierra VM again (which reports as having Clang 9) and tried a simple `clang -std=c11 foo.c` - it doesn't complain about `c11` being invalid (which it does if I try say `-std=c17`) Is there a specific branch in the repo (or in a fork) that already uses the required features? I can try to compile on this VM, to confirm whether it actually works. Cheers Stephen --- ## #124805 — Peter Kokot — 2024-08-06T13:01:43+00:00 URL: https://externals.io/message/124706#124805 · In reply to: #124781 > But what about other compilers we support on non Windows platforms > currently, like clang, Apple's clang, Solaris Studio and maybe some more > we don't even know about. Might be worth noting here that from what I've tested so far that PHP cannot be built currently with Solaris Studio compiler and most likely any other compiler out of the range of MSVC, GCC and Clang (including the AppleClang). There are errors in the configure steps due to not properly checked linker flags and there are lots of warnings and errors produced during the make step. So, basically the list of "supported" and heavily tested compilers is at this point: GCC and Clang. I find this strange, but it also makes sense to not be able to support a wide variety of compilers without having additional CI builds. A nice list of "relevant" compilers from the build system point of view for some overview: https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_ID.html --- ## #124806 — Pierre Joye — 2024-08-06T13:23:14+00:00 URL: https://externals.io/message/124706#124806 · In reply to: #124781 > > > > > […] > > But what about other compilers we support on non Windows platforms > currently, like clang, Apple's clang, Solaris Studio and maybe some more > we don't even know about. Sorry, I meant to actually check if that feature is supported with AC_COMPILE_*. It is painful but has proven to be the only reliable way. As gcc or VCC can be slightly more trusted using their versions, the other, especially on MacOs, can't be trusted, ever. Let alone on other OSes I still wonder why we support them for latest php 8 versions (solaris f.e.). > > […] > > It's supposed to be introduced as of PHP 8.4.0, which already uses VS > 17, although MSVC supports C11 as of VS 16.5 (while it never claimed to > support C99). So in practise, even those still building their own > Windows binaries with Visual Studio 2019 should not be affected. > > > […] > > I somewhat doubt that; we're using a couple of C99 features (like mixed > declarations and statements) in the core for a couple of years (IIRC, as > of PHP 8.0.0), and extensions may do this with their own code, or might > be forced to include public php-src headers which may use some C99 > features. This may not be an issue with any C compilers actually still > in use, but can be sure about that? We can't :). To my understanding the challenges are the extensions maintainers. On Windows it is a controlled environment. We had similar discussions back then when we dropped VC6, which was a much bigger step. I would prefer to go with what makes your work easier than trying to keep older VC support for the latest release, in case we decide to support a minimum VC version for valid reasons. atomic support seems to be one, the header one, I am very doubtful about it as something worth the troubles :). This is being only about windows, that's indeed not valid for any linux/*bsd/*wrt/etc. cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #124807 — Christoph M. Becker — 2024-08-06T14:04:46+00:00 URL: https://externals.io/message/124706#124807 · In reply to: #124805 > > > […] > > Might be worth noting here that from what I've tested so far that PHP > cannot be built currently with Solaris Studio compiler and most likely > any other compiler out of the range of MSVC, GCC and Clang (including > the AppleClang). There are errors in the configure steps due to not > properly checked linker flags and there are lots of warnings and > errors produced during the make step. So, basically the list of > "supported" and heavily tested compilers is at this point: GCC and > Clang. Oh! I wasn't aware of that. > I find this strange, but it also makes sense to not be able to support > a wide variety of compilers without having additional CI builds. Well, users of other compilers could file bug reports, and we could possibly address them even without setting up another CI build (it seems those not using Github runners are already not really helpful). > A nice list of "relevant" compilers from the build system point of > view for some overview: > https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_ID.html Interesting, thanks! While I would not have expected that php-src can be built on all of these, at least I thought some of these were supported. Christoph --- ## #124816 — Lanre — 2024-08-06T20:21:56+00:00 URL: https://externals.io/message/124706#124816 · In reply to: #124706 > Hi everyone > > We've gotten a bug report about compile errors in the PHP 8.4 alpha on > old C99 compilers (and on some modern compilers when passing the > -std=c99 flag). Specifically, C99 does not support typedef > redeclarations, which is a C11 feature. > > ```c > // some_header.h > typedef struct _zval_struct zval; > void some_func(zval *zv); > > // zend_types.h > struct _zval_struct { ... }; > typedef struct _zval_struct zval; > ``` > > Some headers might want to forward declare zval so that zend_types.h > doesn't have to be included. The two primary reasons you might want to > avoid that are 1. to reduce compile times if the header is very large > and 2. to prevent recursive header dependencies. > > However, in C99 this code is actually illegal if both of these headers > end up being included, because redeclarations of typedefs are not > allowed. To fix it, the typedef must be removed and the signatures > must refer to the struct directly. > > ```c > // some_header.h > struct _zval_struct; > void some_func(struct _zval_struct *zv); > ``` > > I started fixing these in a PR [1] which required more changes than > expected. After a short discourse, we were wondering whether it might > be better to switch to a newer C standard instead. Our coding > standards [2] currently specify that compiling php-src requires C99. > The Unix installation page on php.net [3] claims it is ANSI C, which > is certainly outdated. There have been suggestions to require C11 for > a while, which should be well supported by all compilers shipped with > maintained distributions. > > GCC gained support for C11 in 4.7 [4], LLVM Clang in 3.1, both > released in 2012. For context, Debian Bullseye comes with GCC 10.2 > [5], Ubuntu Focal Fossa comes with GCC 9.3 [6], RHEL 8 comes with GCC > 8.x [7]. The biggest blocker in the past was MSVC, which has finally > added C11 support in Visual Studio 2019 [8]. Technically, Visual > Studio 2015 and 2017 are still supported by Microsoft [9], but > according to Christoph they are no longer used for PHP builds since > version 8. > > Hence, it seems like it would be ok to bump our C compiler requirement > to C11. We'd like to make this change before beta 1 if there are no > objections. There are no immediate plans to make non-optional use of > other C11 features, although that is conceivable at some point. > > Another benefit brought up by Christoph is that C11 relegated the > requirement for the compiler to support VLAs (variable-length arrays) > which was never implemented by MSVC, technically not complying with > the currently required standard. > > If you do have any concerns, please let me know. > > Ilija > > [1] https://github.com/php/php-src/pull/15079 > [2] [ > https://github.com/php/php-src/blob/8b6f14a9a221599b076e4bc3570f013a7e65aa21/CODING_STANDARDS.md?plain=1#L12](https://github.com/php/php-src/blob/8b6f14a9a221599b076e4bc3570f013a7e65aa21/CODING_STANDARDS.md?plain=1#L12) > [3] https://www.php.net/manual/en/install.unix.php > [4] https://stackoverflow.com/a/16256596 > [5] https://packages.debian.org/bullseye/gcc > [6] https://packages.ubuntu.com/focal/gcc > [7] https://access.redhat.com/solutions/19458 > [8] > https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ > [9] > https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing Would now be a good time to consider switching to cmake? Peter(petk) has a cmake build system on his github that just needs to be touched up. --- ## #124817 — Christoph M. Becker — 2024-08-06T21:15:45+00:00 URL: https://externals.io/message/124706#124817 · In reply to: #124816 > > > > […] > > Would now be a good time to consider switching to cmake? Peter(petk) has a > cmake build system on his github that just needs to be touched up. I would suggest to start an own thread about this, since these appear to be mostly unrelated issues. Christoph --- ## #124836 — Christoph M. Becker — 2024-08-10T12:19:45+00:00 URL: https://externals.io/message/124706#124836 · In reply to: #124706 > Hence, it seems like it would be ok to bump our C compiler requirement > to C11. We'd like to make this change before beta 1 if there are no > objections. There are no immediate plans to make non-optional use of > other C11 features, although that is conceivable at some point. So skimming the whole discussion[1] it seems that most are generally fine with bumping the requirements to C11, except for Giovanni Giacobbi (whose draft PR[2] had no further discussion so far), and maybe for some uncertainties regarding some less used compilers. Given that feature freeze is in 3 days[3], it appears to be prudent to have a final decision now, and to close PR #15079[4] if we're going with C11, or merge that or Giovanni's PR[2], otherwise. And if we're going with C11, figuring out the details (which configuration check to use, or only documenting the requirement) can still be decided somehwat later, in my opinion. [1] [2] [3] [4] Cheers, Christoph --- Next page: https://externals.io/message/124706.md?page=2