RFC: reformatting code to GNU style

[Joseph Myers <joseph at codesourcery dot com>]

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/glibc/wiki/Style_and_Conventions> references 
<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 
beneficial.

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
joseph@codesourcery.com