Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124716
Precedence: bulk
MIME-Version: 1.0
References: <CAPyj-LB11wiZyHV8=7fEs=J==tDO+m+z4qRsXRroPnqXzNZvvg@mail.gmail.com>
In-Reply-To: <CAPyj-LB11wiZyHV8=7fEs=J==tDO+m+z4qRsXRroPnqXzNZvvg@mail.gmail.com>
Date: Fri, 2 Aug 2024 14:33:53 +0200
Message-ID: <CAML1Pf4AA9Df9JdQTEb9W8TzOfAi=z-RDrK+oAxog0++9RN_ZA@mail.gmail.com>
Subject: Re: [PHP-DEV] Require C11 in PHP 8.4
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ec1510061eb28a40"
From: giovanni@giacobbi.net (Giovanni Giacobbi)

--000000000000ec1510061eb28a40
Content-Type: text/plain; charset="UTF-8"

On Thu, 1 Aug 2024 at 23:57, Ilija Tovilo <tovilo.ilija@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.

--000000000000ec1510061eb28a40
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, 1 Aug 2024 at 23:57, Ilija Tovilo=
 &lt;<a href=3D"mailto:tovilo.ilija@gmail.com">tovilo.ilija@gmail.com</a>&g=
t; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">[...]<br>I started fixing these in a PR [1] which requ=
ired more changes than<br>
expected. After a short discourse, we were wondering whether it might<br>
be better to switch to a newer C standard instead. Our coding<br>
standards [2] currently specify that compiling php-src requires C99.<br>
The Unix installation page on <a href=3D"http://php.net" rel=3D"noreferrer"=
 target=3D"_blank">php.net</a> [3] claims it is ANSI C, which<br>
is certainly outdated. There have been suggestions to require C11 for<br>
a while, which should be well supported by all compilers shipped with<br>
maintained distributions.<br></blockquote><div><br></div><div>It feels wron=
g 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.</div><div><br></div><div>I =
quickly put together an alternative PR (#15202) with a slightly=C2=A0differ=
ent approach, just as a proof of concept. The idea is to move all the globa=
l typedefs in a new include header &quot;zend_types_defs.h&quot; (but also =
zend_portability.h can be reused for this purpose, as all the relevant file=
s already include it).</div><div><br></div><div>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 t=
he design right.</div><div><br></div></div></div>

--000000000000ec1510061eb28a40--