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.
So skimming the whole discussion[1] it seems that most are generally
fine with bumping the requirements to C11, except for Giovanni Giacobbi
(whose draft PR[2] had no further discussion so far), and maybe for some
uncertainties regarding some less used compilers.
Given that feature freeze is in 3 days[3], it appears to be prudent to
have a final decision now, and to close PR #15079[4] if we're going with
C11, or merge that or Giovanni's PR[2], otherwise.
And if we're going with C11, figuring out the details (which
configuration check to use, or only documenting the requirement) can
still be decided somehwat later, in my opinion.
On Sat, Aug 10, 2024 at 2:19 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:
On 01.08.2024 at 23:57, Ilija Tovilo wrote:
So skimming the whole discussion[1] it seems that most are generally
fine with bumping the requirements to C11, except for Giovanni Giacobbi
(whose draft PR[2] had no further discussion so far), and maybe for some
uncertainties regarding some less used compilers.
Giovanni's remark that this would impact many people was challenged by
Jakub [1] which didn't get a response. I believe it's safe to assume
that this isn't the case.
And if we're going with C11, figuring out the details (which
configuration check to use, or only documenting the requirement) can
still be decided somehwat later, in my opinion.
The consensus seems to be that bumping to C11 is ok. While keeping C99
compatibility wouldn't be a big hassle, it doesn't seem necessary
anymore.
I would agree with Christoph that documentation is enough for now. If
your compiler happens to support all the C11 features we require,
without full C11 compliance, then that's ok. If we want to reduce bug
reports, a configure check for typedef redeclarations, nudging people
in the right direction with an appropriate message might help.
Verifying C11 support might be tricky, given that the compiler flags
are not standardized. But I'm not a build system expert, there might
be an approach I'm not aware of.
Giovanni's remark that this would impact many people was challenged by
Jakub [1] which didn't get a response. I believe it's safe to assume
that this isn't the case.
I somehow forgot to link this reference, sorry about that.
On Sat, Aug 10, 2024 at 2:19 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:
On 01.08.2024 at 23:57, Ilija Tovilo wrote:
So skimming the whole discussion[1] it seems that most are generally
fine with bumping the requirements to C11, except for Giovanni Giacobbi
(whose draft PR[2] had no further discussion so far), and maybe for some
uncertainties regarding some less used compilers.
Giovanni’s remark that this would impact many people was challenged by
Jakub [1] which didn’t get a response. I believe it’s safe to assume
that this isn’t the case.
I’d like to remark that this is not a decision about renouncing some valuable feature in order to support older compilers, but rather about applying a patch shy of ~100 lines where half of the changes should be considered bugfixes.
If you think it would be acceptable to have an additional header file pre-declaring the typedefs, it would solve the only standing issue that prevents the entire codebase to be C99 compliant. Isn’t it worth it? The more systems that can bild PHP, the better
Also this is not a binding decision: If in the future there is a real need to increase the requirement to C11, you can always do that.
On Sunday, 11 August 2024 at 17:27, Giovanni Giacobbi <giovanni@giacobbi.net> wrote:
On Sun, 11 Aug 2024 at 16:12, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
Hi Christoph
On Sat, Aug 10, 2024 at 2:19 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:
On 01.08.2024 at 23:57, Ilija Tovilo wrote:
So skimming the whole discussion[1] it seems that most are generally
fine with bumping the requirements to C11, except for Giovanni Giacobbi
(whose draft PR[2] had no further discussion so far), and maybe for some
uncertainties regarding some less used compilers.
Giovanni's remark that this would impact many people was challenged by
Jakub [1] which didn't get a response. I believe it's safe to assume
that this isn't the case.
I'd like to remark that this is not a decision about renouncing some valuable feature in order to support older compilers, but rather about applying a patch shy of ~100 lines where half of the changes should be considered bugfixes.
If you think it would be acceptable to have an additional header file pre-declaring the typedefs, it would solve the only standing issue that prevents the entire codebase to be C99 compliant. Isn't it worth it? The more systems that can bild PHP, the better
Also this is not a binding decision: If in the future there is a real need to increase the requirement to C11, you can always do that.
Even with this change we would not be fully C99 compliant, as we do rely on GCC extensions AFAIK.
Moreover, a bunch of us *want* to move to C11/C17.
C11 is a standard that is 13 years old, and C99 is 25 years old, I think it is totally reasonable for us to bump the language spec we rely on.
Finally, I would like to, once again, see a system where moving to C11 is an actual problem.
On Sat, Aug 10, 2024 at 6:22 AM Christoph M. Becker <cmbecker69@gmx.de> wrote:
On 01.08.2024 at 23:57, Ilija Tovilo wrote:
> 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.
So skimming the whole discussion[1] it seems that most are generally
fine with bumping the requirements to C11, except for Giovanni Giacobbi
(whose draft PR[2] had no further discussion so far), and maybe for some
uncertainties regarding some less used compilers.
Given that feature freeze is in 3 days[3], it appears to be prudent to
have a final decision now, and to close PR #15079[4] if we're going with
C11, or merge that or Giovanni's PR[2], otherwise.
And if we're going with C11, figuring out the details (which
configuration check to use, or only documenting the requirement) can
still be decided somehwat later, in my opinion.
Given the timetable, I wouldn't change the C std requirements for 8.4.
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.
On Mon, Aug 12, 2024 at 5:56 PM 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 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.
On Tue, Aug 13, 2024 at 8:17 AM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
Hi Levi
On Mon, Aug 12, 2024 at 5:56 PM 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.
On Tue, Aug 13, 2024 at 5:00 PM Levi Morrison
<levi.morrison@datadoghq.com> wrote:
On Tue, Aug 13, 2024 at 8:17 AM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
>
> 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.
Thank you for the clarification. In that case, I'd say let's go
forward with the proposal. I agree that we should be making use of
more C11 features in the future, once the opportunity presents itself.
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.
I agree. I will create a PR to provide a ./configure time error
message if the compiler doesn't support typedef redeclarations.
Adopting C11 does mean we can start using other C11 features too,
though that should naturally happen only on (future) master rather
than 8.4, given that ABI freeze is only a little over a month away.
