Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124920
Precedence: bulk
MIME-Version: 1.0
References: <CAPyj-LB11wiZyHV8=7fEs=J==tDO+m+z4qRsXRroPnqXzNZvvg@mail.gmail.com>
 <9e1068ae-593e-40bc-91d7-dd63545d9e60@gmx.de> <CAAKU0ukMEAdCYQmti=aqM7QyjtnuzOx6fCd0aWGGf6EN3CRZBw@mail.gmail.com>
 <CAPyj-LCArhAARxFrCh+9C4T2oj=3EL1vy98+whuStjsBHJAMCQ@mail.gmail.com>
In-Reply-To: <CAPyj-LCArhAARxFrCh+9C4T2oj=3EL1vy98+whuStjsBHJAMCQ@mail.gmail.com>
Date: Tue, 13 Aug 2024 09:00:22 -0600
Message-ID: <CAAKU0uk+wwDp0Ujz7CRO-S8SA-qEaGrX7w-eUx5zFCTsUf8cOQ@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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: levi.morrison@datadoghq.com (Levi Morrison)

On Tue, Aug 13, 2024 at 8:17=E2=80=AFAM Ilija Tovilo <tovilo.ilija@gmail.co=
m> wrote:
>
> Hi Levi
>
> On Mon, Aug 12, 2024 at 5:56=E2=80=AFPM Levi Morrison
> <levi.morrison@datadoghq.com> wrote:
> >
> > Given the timetable, I wouldn't change the C std requirements for 8.4.
>
> Just to state it officially: You object to switching to C11 in 8.4? In
> that case, we'll have to postpone.

I don't object. I think it's smarter to wait, and do more than just
redeclare a few typedefs. But I won't block it.

> > I would stop relying on the typedef and forward declare only the
> > struct, and that. Note that although Windows supports C11, it does not
> > support all features including atomics. Someone chimed in to say that
> > they are available, but this doesn't match the information I got from
> > a coworker who did a similar test. Given conflicting information and
> > the short timetable, I think we should lean towards being cautious. I
> > hope for 8.5/9.0 we can move to C11/C17 which can improve the typedef
> > situation, simplify our atomics handling, and more.
>
> I'm a bit confused about the relevance of C11 atomics. As I'm sure
> you're aware, they remain optional in C17/C23. So, we'll need to
> support a fallback, my suggestion was not to remove the fallback.
>
> Essentially, code-wise, nothing would change if we adopt C11, except
> being allowed to redeclare typedefs. Apart from that, only the
> documentation would change.

If only documentation changes, then I think the risk is lower. We
definitely should not be doing configure checks in 8.4 with how little
time there is, except maybe _one_ that attempts to redeclare a typedef
to see if it compiles, and give a nicer error message.