This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Style and Conventions: Multi-line function-like macro formatting.


On Thu, 18 Jan 2018, Carlos O'Donell wrote:

> I have added my notes on the topic here in Style and Conventions.
> 
> https://sourceware.org/glibc/wiki/Style_and_Conventions#Multi-line_function-like_macros
> 
> Please feel free to tell me I'm wrong :-)

I'm not aware of any preference for the ({ }) form unless you actually 
logically want an expression (for use within other expressions) rather 
than a statement.  (A special case for using ({ }) when statements would 
be more natural is if you want to use it inside ? : conditionals, to avoid 
certain GCC warnings that are disabled in the false half of such 
conditionals with constant condition, but not inside if (0).  But I don't 
think that's ever a case for defining a macro to expand to use ({ }) if it 
doesn't have a useful value, as the caller can always use ({ }) if 
necessary to avoid such warnings, to put a statement inside an 
expression.)

For indentation and backslash positioning I'd consider the preference to 
be "what GNU Emacs does so that pressing TAB on each line doesn't change 
anything", unless Emacs messes up the formatting of a particular 
construct.  But such a rule would need an actual specification of what 
Emacs does that's easy to follow in other editors.  Note that this means 
that the ({ }) in your example would be indented two columns.  It also 
means the backslash on the #define line is lined up with those on other 
lines (except in some cases where some lines go very close to 79 
characters).

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]