Poll Created Mon 19 May 2025 7:30AM
Switching from ansi-c to c-99. You have until Fri 30 May 2025 5:00PM to participate.
The PR-draft here shows my attempt to replace current `BIO_snprintf()` (et.al.) implementation with `snprintf()` found in libc. The deal breaker was missing `va_copy()` which is not part of ansi-c, it's part of C-99. This poll seeks a consensus among OpenSSL committers, so Shane Lontis can bring the topic to Business/Techincal Advisory Committee. Please keep in mind this is about moving away from ansi-c to C-99.
Current results
| Current results | Option | % of points | Voters | |
|---|---|---|---|---|
|
|
sooner the better | 53.3% | 8 |
|
| yes, but not now. | 40.0% | 6 |
|
|
| I prefer to stick to ansi-c instead of moving C-99 | 6.7% | 1 |
|
|
| Undecided | 0% | 5 |
|
15 of 20 people have participated (75%)
Dmitry Belyavsky
Mon 19 May 2025 7:30AM
I presume that
- "Yes but not now" implies 4.0 (no later than spring 2026)
- The voices for (1) and (2) will be summarized making the decision whether we do this step at all
Paul Dale
Mon 19 May 2025 7:30AM
We're using plenty of C99 features already, might as well formalise it.
Tomas Mraz
Mon 19 May 2025 7:30AM
I am fine with starting the conversation but IMO to be able to decide we have to evaluate which are those legacy platforms (in the list of build targets) that have just C-90 compilers. Then, if we are ready to drop them, we can move to C-99.
Nicola Tuveri
Mon 19 May 2025 7:30AM
I would like to see a list of which platforms in our tiered supported platforms list will be affected by this (because they do not officially have fully compliant c99 toolchains).
Even if the disruption is limited, I think this is a breaking change, and as such should wait for the next major release.
In terms of stability guarantees, as a project , we have committed to a quite high bar so even aiming for next major release, we would need to start making moves now to involve communities in time
Richard Levitte
Mon 19 May 2025 7:30AM
I'm all for it, generally speaking. However, switching to c99 may be a breaking change for some platforms, still. Therefore, it would be better to do that switch in 4.0
Tim Hudson
Mon 19 May 2025 7:30AM
I would express it differently - that we should pick a subset of the full standard and move forward as quickly as possible. We should have a test program that contains all of what we think should be allowed to be used and allow that to be run on each platform. Before moving or allowing a new C99 feature to be used, we should test that it works across all the primary and secondary platforms and all the platforms in CI (which is a wider set). Full C99 is not widely supported.
Matt Caswell
Mon 19 May 2025 7:30AM
The option description doesn't really express my view, but it's the closest option available. We already use C99 features - often with some kind of fallback for if that feature is not available. This seems to work perfectly well and I don't know what the "killer feature" is that makes a move to C-99 a "must have". If there are specific features we want to use then we have a well established approach for introducing them.
Sasha Nedvedicky Tue 20 May 2025 1:08AM
the `killer feature` for me is what's found in referenced PR:
va_copy()
s*printf() provided by libc
this will allow us to simplify the implementation of BIO_*print*() functions we have. I strongly believe we are better to drop this code in favor of using libc implementation. The MSVC before 2015 takes slightly different approach to sprint() et. al. but there is a way to deal with it for those old versions.
The platforms which miss sprintf() functions completely should provide their own implementation. I think those platforms should be keeping their own specific patch against OpenSSL which implements sprintf(). I think it is fair assumption. No one should be expecting crypto/ssl library will be providing those fundamentals. That's my opinion.
Tim Hudson · Mon 19 May 2025 3:45PM
My thoughts here are that we are probably in agreement to use more C99 features if we know those are okay on all the platforms we currently test and to do it sooner than 4.0 if we don't have a blanket all-C99 decision - i.e. knowing the impact is minimal because we don't test the boundaries might make the view different.
My vote position is on the basis that I think we have been holding back on some C99 features which are widely enough supported now that they are safe enough to use without causing issues.