All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Denton Liu <liu.denton@gmail.com>
Subject: Re: [RFC] CodingGuidelines: mark external declarations with "extern"
Date: Fri, 09 Oct 2020 13:33:39 -0700	[thread overview]
Message-ID: <xmqqpn5rrvfg.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20201009195701.GA967869@coredump.intra.peff.net> (Jeff King's message of "Fri, 9 Oct 2020 15:57:01 -0400")

Jeff King <peff@peff.net> writes:

> The argument for including it is less clear to me. You say below:
>
>> [...]By doing so, we would also prevent a
>> mistake of not writing "extern" when we need to (i.e. decls of data
>> items, that are not functions) when less experienced developers try
>> to mimic how the existing surrounding declarations are written.
>
> but to my recollection that has not been a big problem. And it's one
> that's usually easily caught by the compiler. A missing "extern" on a
> variable will usually get you a multiple-definition warning at
> link-time (if you manage to also omit the actual definition you won't
> see that, though "make sparse" will warn that your variable ought to be
> static).

Not really, that is where the "common" extension comes in, to help
us with it hurt others without it, unknowingly X-<.

        $ cat >a.c <<\EOF
        #include <stdio.h>
        #include "c.h"

        int common = 47;

        int main(int ac, char **av)
        {
            printf("%d\n", common + other);
            return 0;
        }
        EOF
        $ cat >b.c <<\EOF
        #include "c.h"

        int other = 22;
        EOF
        $ cat >c.h <<\EOF
        int common;
        int other;
        EOF
        $ gcc -Wall -o c a.c b.c; ./c
        59

And I have a strong preference, after thinking about it, to have
"extern" in front in the declarations.  It gives another clue for
patterns I feed to "git grep" to latch onto, and help my eyes to
scan and tell decls and defns apart in the output.  The benefit
alone is worth the extra 7 columns in front spent, which you call
"clutter".

> IMHO the real problem here is that C's syntax for returning a function
> pointer is so horrendous. How about this (on top of your earlier patch
> to drop the extern from that declaration)?

In general, I like a typedef for callback function that shortens the
decl of a function that takes such a callback, so I think

> +void set_error_routine(report_fn routine);
> +void set_warn_routine(report_fn routine);
> +report_fn get_error_routine(void);
> +report_fn get_warn_routine(void);

these are good, but they are better with "extern" in front in a
header file to make it clear they are declarations and not
definitions when they appear in "git grep" output.

  reply	other threads:[~2020-10-09 20:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-08 15:27 [PATCH] clean up extern decl of functions Junio C Hamano
2020-10-09  1:55 ` Denton Liu
2020-10-09  2:47   ` Junio C Hamano
2020-10-09 19:26     ` Junio C Hamano
2020-10-09 19:27       ` [RFC] CodingGuidelines: mark external declarations with "extern" Junio C Hamano
2020-10-09 19:57         ` Jeff King
2020-10-09 20:33           ` Junio C Hamano [this message]
2020-10-09 23:00             ` Denton Liu
2020-10-09 23:05               ` Junio C Hamano
2020-10-10  0:37             ` Đoàn Trần Công Danh
2020-10-15  1:36             ` Jeff King
2020-10-15 17:15               ` Junio C Hamano
2020-10-15 19:28                 ` Jeff King
2020-10-15 19:30                   ` [PATCH v2 1/2] usage: define a type for a reporting function Jeff King
2020-10-15 19:30                   ` [PATCH v2 2/2] config.mak.dev: build with -fno-common Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqpn5rrvfg.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=liu.denton@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.