Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Jan 2018 22:41:23 -0600
From: Samuel Holland <>
To:, Jens Gustedt <>
Subject: Re: automated coding style


On 01/03/18 08:08, Jens Gustedt wrote:
> On Thu, 21 Dec 2017 18:34:02 -0500 Rich Felker <> wrote:
>> On Thu, Dec 21, 2017 at 12:06:55PM +0100, Jens Gustedt wrote:
>>>> There seems to be some mixing of tabs and spaces here and in a few 
>>>> other lines. Tabs should be used for indentation levels, spaces (after 
>>>> any initial indent) to column-align. Generally musl style also has 
>>>> continuation comment lines begin with a * aligned with the * of the 
>>>> opening /* too.
>>> Since I ran into similar comments before and I find it quite frustrating 
>>> and disruptive:
>> By similar comments do you mean existing comments in the musl source
>> styled like you did it, or similar email comments before about styling
>> matters?
> comments about style.
> it think an automatic formatting procedure that accommodates everybody could 
> help us focus on contents
>> I'm not familiar with these tools, so I could look into it, but someone 
>> else interested might be able to get to it before me. I'll see. The way I 
>> deal with touching code in lots of different projects with different
>> styles is having my editor configured to copy exactly the leading
>> whitespace of the previous line when adding a new line, and then adding or
>> deleting tabs or spaces as appropriate. But I can see how that's not
>> agreeable to everyone.
>> Actually now that I think about it, I'm pretty sure the official Linux 
>> kernel style is nearly the same as preferred style in musl, and should 
>> usually produce formatting that's perfectly acceptable.
> so for my latest patches I experimented with
> astyle --style=linux --indent=tab
> This helps a lot, already. Unfortunately, this combination still changes
> some musl sources, basically because indentation of continuation lines is
> handled differently.

I'm familiar with three source code formatting tools for C: astyle,
clang-format, and uncrustify. I haven't used astyle, because it seems to be the
least flexible of the three.

clang-format is very stable and consistent, and has a moderate number of
configuration options. However, because it is designed for use with C++, it has
poor handling of C braced initializers, especially designated initializers. It
also is unable to align macro definitions, making it unusable on musl's headers.
The changeset for this feature has been open for over a year and doesn't look
like it will be merged soon:

uncrustify is the most flexible of the three, making it the best for matching an
existing code style. It's also a bit buggier than clang-format, especially when
the tool wraps long lines for you (though this doesn't affect code already
following a line length limit).

I wrote a script to permute over 600 of the options to uncrustify and generate a
configuration with the smallest diff from the current musl source. Attached is
that configuration file, as well as a diffstat from 628cf979b249. You can see
most of the changes are in the inline assembly syntax, continuation of header
namespace guards, and the imported code in src/math and src/regex.

I don't claim that this file represents the "official musl style", especially
because it's autogenerated, but hopefully it's useful for formatting patches.


View attachment "uncrustify" of type "text/plain" (15471 bytes)

View attachment "diffstat" of type "text/plain" (18373 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.