Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124816
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: Tue, 6 Aug 2024 14:21:56 -0600
Message-ID: <CAM7F2-_kGwAqjx9PpnJvhJy2SeB9z5S6RSJH_rZoC3MUH7Q+XQ@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="0000000000001c98fc061f098c6f"
From: lnearwaju@gmail.com (Lanre)

--0000000000001c98fc061f098c6f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 1, 2024 at 4:01=E2=80=AFPM Ilija Tovilo <tovilo.ilija@gmail.com=
> wrote:

> 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=3Dc99 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/8b6f14a9a221599b076e4bc3570f013a7e65a=
a21/CODING_STANDARDS.md?plain=3D1#L12](https://github.com/php/php-src/blob/=
8b6f14a9a221599b076e4bc3570f013a7e65aa21/CODING_STANDARDS.md?plain=3D1#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-arriv=
ing-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.

--0000000000001c98fc061f098c6f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 1, 2024 at 4:01=E2=80=AFPM Il=
ija Tovilo &lt;<a href=3D"mailto:tovilo.ilija@gmail.com" target=3D"_blank">=
tovilo.ilija@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">Hi everyone<br>
<br>
We&#39;ve gotten a bug report about compile errors in the PHP 8.4 alpha on<=
br>
old C99 compilers (and on some modern compilers when passing the<br>
-std=3Dc99 flag). Specifically, C99 does not support typedef<br>
redeclarations, which is a C11 feature.<br>
<br>
```c<br>
// some_header.h<br>
typedef struct _zval_struct zval;<br>
void some_func(zval *zv);<br>
<br>
// zend_types.h<br>
struct _zval_struct { ... };<br>
typedef struct _zval_struct zval;<br>
```<br>
<br>
Some headers might want to forward declare zval so that zend_types.h<br>
doesn&#39;t have to be included. The two primary reasons you might want to<=
br>
avoid that are 1. to reduce compile times if the header is very large<br>
and 2. to prevent recursive header dependencies.<br>
<br>
However, in C99 this code is actually illegal if both of these headers<br>
end up being included, because redeclarations of typedefs are not<br>
allowed. To fix it, the typedef must be removed and the signatures<br>
must refer to the struct directly.<br>
<br>
```c<br>
// some_header.h<br>
struct _zval_struct;<br>
void some_func(struct _zval_struct *zv);<br>
```<br>
<br>
I started fixing these in a PR [1] which required 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>
<br>
GCC gained support for C11 in 4.7 [4], LLVM Clang in 3.1, both<br>
released in 2012. For context, Debian Bullseye comes with GCC 10.2<br>
[5], Ubuntu Focal Fossa comes with GCC 9.3 [6], RHEL 8 comes with GCC<br>
8.x [7]. The biggest blocker in the past was MSVC, which has finally<br>
added C11 support in Visual Studio 2019 [8]. Technically, Visual<br>
Studio 2015 and 2017 are still supported by Microsoft [9], but<br>
according to Christoph they are no longer used for PHP builds since<br>
version 8.<br>
<br>
Hence, it seems like it would be ok to bump our C compiler requirement<br>
to C11. We&#39;d like to make this change before beta 1 if there are no<br>
objections. There are no immediate plans to make non-optional use of<br>
other C11 features, although that is conceivable at some point.<br>
<br>
Another benefit brought up by Christoph is that C11 relegated the<br>
requirement for the compiler to support VLAs (variable-length arrays)<br>
which was never implemented by MSVC, technically not complying with<br>
the currently required standard.<br>
<br>
If you do have any concerns, please let me know.<br>
<br>
Ilija<br>
<br>
[1] <a href=3D"https://github.com/php/php-src/pull/15079" rel=3D"noreferrer=
" target=3D"_blank">https://github.com/php/php-src/pull/15079</a><br>
[2] [<a href=3D"https://github.com/php/php-src/blob/8b6f14a9a221599b076e4bc=
3570f013a7e65aa21/CODING_STANDARDS.md?plain=3D1#L12](https://github.com/php=
/php-src/blob/8b6f14a9a221599b076e4bc3570f013a7e65aa21/CODING_STANDARDS.md?=
plain=3D1%23L12)" rel=3D"noreferrer" target=3D"_blank">https://github.com/p=
hp/php-src/blob/8b6f14a9a221599b076e4bc3570f013a7e65aa21/CODING_STANDARDS.m=
d?plain=3D1#L12](https://github.com/php/php-src/blob/8b6f14a9a221599b076e4b=
c3570f013a7e65aa21/CODING_STANDARDS.md?plain=3D1#L12)</a><br>
[3] <a href=3D"https://www.php.net/manual/en/install.unix.php" rel=3D"noref=
errer" target=3D"_blank">https://www.php.net/manual/en/install.unix.php</a>=
<br>
[4] <a href=3D"https://stackoverflow.com/a/16256596" rel=3D"noreferrer" tar=
get=3D"_blank">https://stackoverflow.com/a/16256596</a><br>
[5] <a href=3D"https://packages.debian.org/bullseye/gcc" rel=3D"noreferrer"=
 target=3D"_blank">https://packages.debian.org/bullseye/gcc</a><br>
[6] <a href=3D"https://packages.ubuntu.com/focal/gcc" rel=3D"noreferrer" ta=
rget=3D"_blank">https://packages.ubuntu.com/focal/gcc</a><br>
[7] <a href=3D"https://access.redhat.com/solutions/19458" rel=3D"noreferrer=
" target=3D"_blank">https://access.redhat.com/solutions/19458</a><br>
[8] <a href=3D"https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-=
support-arriving-in-msvc/" rel=3D"noreferrer" target=3D"_blank">https://dev=
blogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/<=
/a><br>
[9] <a href=3D"https://learn.microsoft.com/en-us/visualstudio/productinfo/v=
s-servicing" rel=3D"noreferrer" target=3D"_blank">https://learn.microsoft.c=
om/en-us/visualstudio/productinfo/vs-servicing</a></blockquote><div><br></d=
iv><div>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.<=
/div></div></div>

--0000000000001c98fc061f098c6f--