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

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.

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.

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 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.

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.

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.

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.

@Neil Horman 
check-format.pl is quite buggy... I've to waive the style check more often than not.

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).

If we're going for absolute consistency, I'd rather force a line break after the function return type.

@Sasha Nedvedicky I strongly prefer to see consistency here too. Pick one approach and stick to it. We have a lot of the code where the coding style is such that we get personal preferences for approaches that differ which are throughout the code. Picking on consistent style does lead to cleaning looking code.

@Richard Levitte I prefer consistency here. I believe we should choose one and stick to it. I prefer the variant for function `sub()` as it is make navigation in source code easier (finding function definition is easy just /^sub). However consistency takes precedence at least for me.

@Sasha Nedvedicky 
I see nothing wrong with accepting both, mind you... sometimes, our function signatures are really very long, and breaking after the return type has precedents (it's standard in GNU coding recommendations, for example).

No I'm not sure at all however the check-format.pl we use is quite liberal. for example both those two quite different styles below are accepted with no issues:

int add(int a, int b)
{
  return a + b;
}

int
sub(int a, int b)
{
  return a - b;
}