[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <57F1F710-9135-413B-A811-88C1091389AC@moffetthome.net>
Date: Thu, 24 Jan 2008 20:55:47 -0500
From: Kyle Moffett <kyle@...fetthome.net>
To: Dmitri Vorobiev <dmitri.vorobiev@...il.com>
Cc: Heikki Orsila <shdl@...alwe.fi>, trivial@...nel.org,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
tigran@...azian.fsnet.co.uk
Subject: Re: [PATCH 5/9] bfs: move function prototype to the proper header file
On Jan 24, 2008, at 18:13, Dmitri Vorobiev wrote:
> Heikki Orsila пишет:
>> On Fri, Jan 25, 2008 at 01:32:04AM +0300, Dmitri Vorobiev wrote:
>>> +/* inode.c */
>>> +extern void dump_imap(const char *, struct super_block *);
>>> +
>>
>> Functions should not be externed, remove extern keyword.
>
> Care to explain why?
>
> Following is an explanation why the contrary is probably true:
>
> 1) We have lots of precedents in existing code:
>
> dmvo@...her:~/Projects/misc/linux$ git-grep 'extern void' include |
> wc -l
> 5523
> dmvo@...her:~/Projects/misc/linux$
The "extern" keyword on functions is *completely* redundant.
For C variables:
Declaration: extern int foo;
Definition: int foo;
File-scoped: static int foo;
For C functions:
Declaration: void foo(int x);
Definition: void foo(int x) { /*...body...*/ }
File-scoped: static void foo(int x) { /*...body...*/ }
The compiler will *allow* you to use "extern" on the function
prototype, but the presence or absence of a function body is
sufficiently obvious for it to determine whether the prototype is a
declaration or a definition that the "extern" keyword is not required
and therefore redundant.
For maximum readability and cleanliness I recommend that you leave off
the "extern" on the function declarations; it makes the lines much
longer without obvious gain.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists