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
