Communities - Committers

Replacing check-format.pl with clang-format

Anton Arapov Mon 9 Jun 2025 7:38AM Public Seen by 29

Tim Hudson Tue 10 Jun 2025 8:24AM

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

Sasha Nedvedicky Tue 10 Jun 2025 7:08AM

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

Richard Levitte (OpenSSL) Mon 9 Jun 2025 3:34PM

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

Sasha Nedvedicky Mon 9 Jun 2025 8:38AM

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;
}

Tomas Mraz

Mon 9 Jun 2025 5:55AM

Are you absolutely sure all the existing rules (or at least the important ones) enforced by check-format.pl are doable with clang-format?

Richard Levitte (individual)

Mon 9 Jun 2025 5:55AM

A technical note: clang-format, like any formatter, is limited to exactly that, formatting. They are usually not designed to enforce code ordering rules, or to reorder code (such as moving all variable declarations to the start of a block). That's simply out of their scope. To enforce such things, we'd need some sort of linter with that sort of capability, in addition to a formatter.

Sasha Nedvedicky

Mon 9 Jun 2025 5:55AM

I'm for clang-format although there does not seem to be way to ask clang-format to restrict variable declaration. I could not figure out a way to tell clang-format not to allow variable declaration in the middle of the code block.

Replacing check-format.pl with clang-format

proposal by Sasha Nedvedicky Closed Mon 23 Jun 2025 9:00PM

Outcome

by Sasha Nedvedicky Wed 25 Jun 2025 6:17AM

The poll indicates there is 2/3 support for switching to clang-format. On the other hand, 25% committers did not cast their vote. So I would interpret the result as mild interest. Perhaps we need to come up with a more detailed/appealing plan to convince the undecided to cast their vote.

thanks for your participation.

Moving from ANSI-C to C-99 requires us to update C-style. For example, we are already aware that we need to impose some restrictions on where variables can be declared. The C-99 standard is too liberal because it allows variable declaration anywhere. For OpenSSL we might want to restrict the C-99 freedom here and allow variable declarations at the start of the block or inside of conditionally compiled sections (see discussion here). There might be more C-99 constructs that we will need to ban/restrict. Let's leave those for a separate poll/discussion. This decision is about replacing util/check-format.pl with clang-format.

My reasoning about using a clang-format instead of perl script goes as follows:

Adoption of C-99 requires an update to C-style, which will require updating check-format.pl. instead of fixing Perl code, there is an opportunity to replace it with a more recent tool.
Unlike check-format.pl, the clang-format can also format the code to match C-style
clang-format seems to play nicely with git
clang-format comes with plugins for various editors (emacs, vim, VS-code, ...)

Neil and Andrew gave a clang-format try already and the tool can get confused (see details here), but I still think it is a way to go.

In this poll, I'd like to select the tool that will check and format C-style the follow-up polls will be taking decisions on updating the C-style.