Sasha Nedvedicky Tue 10 Jun 2025 7:12AM
IMO we should not be waving c-style. perhaps the only reason to wave c--style is the case when we adopt 3rd-party code which comes from different project. This should be only exception. c-style waiver as being used now makes c-style policy useless/ineffective.
Tomas Mraz Mon 9 Jun 2025 6:33PM
Please understand than any tool we choose will be imperfect and we will always need exceptions to otherwise fairly strict rules. IMO the current CI job with check-format.pl is good enough for checking. Of course being able to format things would be a nice functionality so I am not opposed to moving to something else eventually although I am not sure this is the most pressing thing we should invest our time in right now. What I would not like to see is committing formatting changes on completely unrelated lines just because the editing/formatting tool forces you to do it. This would make a nightmare when backporting patches, etc.
Neil Horman Mon 9 Jun 2025 5:39PM
Agreed, while writing this I recalled this issue:
https://github.com/openssl/openssl/issues/24901
in which you documented several issues that you had run acrossin check-format.pl. If memory serves @Viktor Dukhovni triaged several of the issues, fixed some of them, and determined that the investment of time to fix the remainder likely wasn't worth the effort for the time available ( @Viktor Dukhovni , please correct me here if my recollection is flawed). Assuming my memory is accurate though, if we don't have the time to invest in fixing the tool we have, it seems to me, switching to a tool that is more widely maintained makes sense.
Richard Levitte Mon 9 Jun 2025 3:36PM
@Neil Horman
check-format.pl is quite buggy... I've to waive the style check more often than not.
Neil Horman Mon 9 Jun 2025 1:58PM
I think maintaining both is asking to serve two masters, for which the costs outweigh the benefits. A style should be definitive, and if we need to stray from it, we should document why in the code (clang-format has this feature, which works similarly to how indent does it). As for availability, I agree that check-format.pl is more available than clang-format might be, but I feel like thats the workaround point (i.e. a CI job that checks formatting can easily upload the diff to fix the format errors as an artifact of that job, which developers can just apply if they don't want the tool installed locally).
Todd Short
 sources you suggest?.svg)
Mon 9 Jun 2025 5:55AM
Why not both? clang-format may not be available to everyone, and there's no reason to get rid of a tool that works for everybody. Is it twice the maintenance burden? Unikely. Will there be conflicts? Probably, but they can be resolved/worked-around. It does sound as though clang-format might be more limited in it's functionality.
Frederik Wedel-Heinen
Mon 9 Jun 2025 5:55AM
I vote for adopting clang-format for the checks in check-format.pl that can be implemented using that. Please refer to my comment in the thread.
Matt Caswell
Mon 9 Jun 2025 5:55AM
I'd really like to see such things start as a discussion before going straight to a vote. Votes don't allow you to just post comments without having to make a choice. I believe there are reasons why check-format.pl exists, and why that was chosen over existing formatting tools (I think because it was too difficult to get other tools to do the checks we wanted). I don't know if those reasons still apply. It is the wrong way around to decide to go to some other tool first before evaluating it. If we think check-format.pl no longer meets our needs we should write down what our needs are and evaluate the alternative(s) to determine which one best achieves those needs.
BTW "there is an opportunity to replace it with a more recent tool."...check-format is not even really that old (it was first added in 2020)
Richard Levitte Tue 10 Jun 2025 10:02AM
If we're going for absolute consistency, I'd rather force a line break after the function return type.
Sasha Nedvedicky · Tue 10 Jun 2025 7:47AM
@Tomas Mraz I agree this is going to be a significant bump and I fully understand your concerns here. In my opinion the goal here is to have a style/format consistency in the whole source code base. Not running check-format.pl and then deciding wether code should be fixed to make check-format.pl happy or just press c-style waived button. In my opinion, the rigid c-style with no exceptions is a good thing. Think of a C-style/format as a conductor for a coding orchestra. There is no good performance without a conductor.
All this is heading to `Big Source Code Reformat effort 2.0` IMO it should happen in master branch only.