Hello, 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: https://reviews.llvm.org/D28462 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. Regards, Samuel