This is the mail archive of the
mailing list for the glibc project.
RFC: reformatting code to GNU style
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Wed, 20 Feb 2019 17:54:47 +0000
- Subject: RFC: reformatting code to GNU style
Sometimes we convert existing source files taken from external (e.g. BSD)
sources into GNU style (e.g. commit
5e30b8ef0758763effa115634e0ed7d8938e4bc0, "resolv: Reformat inet_addr,
inet_aton to GNU style", as a recent example).
I'd like to propose that we should have a policy that such reformattings
are considered OK for any non-generated files that are maintained in glibc
rather than being updated on an ongoing basis from external sources. This
would apply both to general GNU style issues (indentation, brace
positioning, where to break lines, where to have spaces, etc.) and also to
glibc-specific rules (preprocessor indentation, saying "long int" instead
of just "long", etc.). That is, where
<https://sourceware.org/ml/libc-alpha/2012-08/msg00182.html> for a rule to
stick to the code formatting conventions in a given file, doing a bulk
reformatting would be listed as an acceptable alternative (without ever
being required as a prerequisite of another change).
This would *not* mean that such bulk changes are considered obvious (where
outside the areas the person proposing such a patch maintains). There
might well be cases where we wish to avoid such changes and review is
In the case where a file is close to GNU style but has a few local
deviations (e.g. missing spaces before '('), I think local fixes to those
deviations should be preferred to reformatting the whole file with e.g.
indent so resulting in other formatting changes where both the old and new
variants would be considered OK by our style. For files with major
deviations from GNU style, however, using tools for a global reformatting
may be better than just addressing individual issues one by one.
One specific case I think makes sense for global reformatting is the
fdlibm code in sysdeps/ieee754/.
Joseph S. Myers