Frederik Wedel-HeinenMon 9 Jun 2025 8:42AM
I’m all for the idea.
However, I also doubt that all of check-format.pl can be performed with clang-format.
So I think the question should be rephrased and the summary should explicitly state which checks should be done with clang-format instead of check-format.pl.
And then whatever checks remains has to be performed with check-format.pl.
Tom Cosgrove
Mon 9 Jun 2025 5:55AM
Surely a change to the format checker is really only necessary if the syntax of the language has changed, which I don't think has happened. Or: what parts of C99 require major (if any) changes to check-format.pl? I too have had bad experiences with clang-format! I'd be inclined to keep check-format.pl and make any tweaks we think are necessary
Shane Lontis
Mon 9 Jun 2025 5:55AM
I think we still some form of linter as well as a formatter.
Paul YangWed 11 Jun 2025 7:00AM
At least we can have a 'caller' script that calls both clang-format and current check-format.pl for different checks. And the final goal is to reduce the effort we need to maintain check-format.pl
Paul YangMon 9 Jun 2025 5:55AM
There's no need to re-invest on tools whose functionality is mainly covered by other tools.
Tim HudsonMon 9 Jun 2025 5:55AM
I think changing to a more widely used tool and adjusting our coding guidelines to fit what the tool can handle makes sense. We still have some "quirky" things in place and some flexibility where we should just pick a single approach. Right now we have too many exceptions and too many code format nits that come up during reviews which should be able to be eliminated by automation of formatting and an adjustment of the coding guidelines.
I would perform a general reformat once we settle on what precisely that format should be and apply it to earlier branches to allow for continued easy backfit of code. My view is the benefit comes from consistency and that means automation as we have seen from the last 10 years of not having an automated format approach.
Neil HormanTue 10 Jun 2025 10:19AM
FWIW, if you look at https://github.com/nhorman/openssl/tree/sample-clang-format It appears that clang-format actually handles our un-terminated macros fairly gracefully. I'm looking at commit 315301e96385c3208b7e35c63beb9759b79b56cc, specifially instances of our use of DEFINE_STACK_OF and IMPLEMENT_ASN1_FUNCTIONS as an example.
Richard Levitte (OpenSSL)Tue 10 Jun 2025 9:58AM
Most of all, check-format.pl sometimes contradicts our coding style.
When that happens, I have zero regrets waiving the C style checks.
Also, we have macros invocations all over the place that look like a function call, but aren't terminated with ';'. That will confuse any source format checker, including clang-format, to the point that their reports are utter rubbish.
When that happens, I have zero regrets waiving the C style checks.
Tomas MrazTue 10 Jun 2025 8:16AM
In my opinion is a completely strict code format checking just breaks readability and usability of the code base. Also due to inevitable weaknesses of the code format tool (it cannot really fully understand the code especially due to our heavy use of macros), it is making our source being dictated by our tools and not by the developers who actually write the code. So I beg to disagree.
Tomas Mraz ·Mon 9 Jun 2025 8:52AM
@Frederik Wedel-Heinen Yes, that sounds to me like the way to go.