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
