Got it. Thanks for the explanation!

On Thu, Jan 1, 2015 at 4:02 PM, Ben Pfaff <b...@nicira.com> wrote:
> On Fri, Dec 19, 2014 at 10:43:01AM -0800, Andy Zhou wrote:
>> On Fri, Dec 19, 2014 at 10:26 AM, Joe Stringer <joestrin...@nicira.com> 
>> wrote:
>> > On 18 December 2014 at 17:16, Andy Zhou <az...@nicira.com> wrote:
>> >> I don't strongly object the current version either (with the fix
>> >> above), but this version seems simpler.
>> >
>> > OK, but this is tangential to the original patch so I'll send it 
>> > separately.
>> >
>> >> Is it worth while to make it inline?
>> >
>> > From CodingStyle:
>> >
>> > Functions in .c files should not normally be marked "inline", because
>> > it does not usually help code generation and it does suppress
>> > compilers warnings about unused functions.  (Functions defined in .h
>> > usually should be marked inline.)
>>
>> If inline make sense, it should be in a header file.  This is not a big deal.
>
> I think you might be misinterpreting what I tried to say there in
> CodingStyle.
>
> "inline" affects GCC and Clang two ways.  First, it encourages them to
> expand the function inline.  Usually this isn't useful because they're
> already pretty good at figuring out what functions should be expanded
> inline.  That's why CodingStyle discourages using "inline" in .c files.
> (Occasionally we do run into a case where "inline" really does make a
> difference and does help, so that's why there's no blanket prohibition
> on "inline" in .c files.)
>
> Second, "inline" suppresses GCC and Clang warnings about unused
> functions.  That makes a lot of sense for inline functions in header
> files, which are often unused, because it means that one does not need
> to add a separate __attribute__((unused)).  But one does normally want
> warnings for unused functions in .c files.
>
> So I'd never tell someone to move a function from a .c file to a .h file
> because it is inline.  Rather, the question is whether the "inline" in
> the .c file is useful; that is, whether it really improves code
> generation.  If not, then I'd remove it.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to