Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124706
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 1 Aug 2024 23:57:36 +0200
Message-ID: <CAPyj-LB11wiZyHV8=7fEs=J==tDO+m+z4qRsXRroPnqXzNZvvg@mail.gmail.com>
Subject: [PHP-DEV] Require C11 in PHP 8.4
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: tovilo.ilija@gmail.com (Ilija Tovilo)

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