Re: [SPATCH] Add space after function call.

["Joseph S. Myers" <joseph at codesourcery dot com>]

For cases such as GLRO, GL and ElfW, where the macro call is more like a 
variable or type name than a function call and almost universal practice 
is not to have the space, I think additions of the spaces would need 
discussing separately.  (There might be other such cases as well.)

The cases of actual function calls are comparatively uncontroversial (and 
likewise cases such as "if(" that this patch also fixes).  But:

* If a change makes a line occupy 80 columns or more that previously 
occupied 79 columns, the code needs wrapping accordingly.

* If the arguments to a function call go only another line, then 
subsequent lines need their indentation adjusted.

* The patch changes intl/plural.c, a generated file; you need to get the 
Bison template fixed in upstream Bison instead.

It should be straightforward to make the code generating these changes 
exclude cases where the line would go to 80 columns or more or where 
parentheses are unbalanced at the end of the line, as well as excluding 
GLRO, GL and ElfW (at least).  (The cases where wrapping is involved could 
then be fixed separately with a patch that involved some manual editing of 
the results of initial automatic running of a script.)  I'd still suggest 
splitting up the resulting changes by directory for easier review.

I suspect that quite a few changes would run into the badly formatted 
lines also having trailing whitespace on them and so being rejected by the 
commit hooks.  While you could remove trailing whitespace as part of the 
patch generation, it may be better to do an initial patch that cleans up 
all the whitespace issues - trailing whitespace, blank lines at end of 
file, spaces before TABs - once and for all (with the usual caveats about 
avoiding changing generated files or files imported from elsewhere, as 
described at <http://sourceware.org/glibc/wiki/Regeneration>).

-- 
Joseph S. Myers
joseph@codesourcery.com