This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Style and Conventions: Multi-line function-like macro formatting.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 18 Jan 2018 16:59:28 +0000
- Subject: Re: Style and Conventions: Multi-line function-like macro formatting.
- Authentication-results: sourceware.org; auth=none
- References: <bdeb4a74-ffeb-6906-d582-f6540de5a2b1@redhat.com>
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