On Sun, Aug 4, 2024 at 10:05 AM Gina P. Banyard <intern...@gpb.moe> wrote: > > > On Friday, 2 August 2024 at 14:33, Giovanni Giacobbi <giova...@giacobbi.net> > wrote: > > On Thu, 1 Aug 2024 at 23:57, Ilija Tovilo <tovilo.il...@gmail.com> wrote: >> >> [...] >> 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. > > > 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`.
