i dont see any reason _not_ to make these particular macros functions... they're only used in the c-file that defines them and not being used to break out of loops or anything.
On 4/19/07, Bernd Schubert <[EMAIL PROTECTED]> wrote:
On Thursday 19 April 2007 14:10:45 David Lee wrote: > On Thu, 19 Apr 2007, Bernd Schubert wrote: > > while looking into the source due to our recent problems, I see there > > are several macros, which could be replaced by static (inline) > > functions, e.g. in GSource.c. > > > > Is there a reason to use macros? Do you mind if I convert this into > > functions? > > My reply here isn't either yes or no. It is simply recollection and > observation from about a year ago. See: > > http://cvs.linux-ha.org/viewcvs/viewcvs.cgi/linux-ha/lib/clplumbing/GSource >.c?r1=1.79&r2=1.80 > > There are some "longclock_t" things in there which benefitted from being > wrapped up as (abstracted into) functions, because of alignment > requirements on some architectures (e.g. sparc) which were being adversely > affected by some suboptimal casting that happened before that (beneficial) > function abstration. > > In short, there are places in GSource.c that are sensitive to > architectural issues for this portable "heartbeat" package. Perhaps you > could describe a little more your intentions (what functions, a sample > rewrite (even if only pseudo-code) etc.). > Attached is a quick shot, even didn't test if it compiles... > > > Incidentally, when you say "static (inline) functions", what do you mean > by "inline"? The "static" qualifier, in this context, simply means that > the function's scope is restricted to that compilation unit and it is not > linkable from other compilation units. I'm not sure what you mean by > "inline". Some optimisation levels of some compilers might choose, under > certain conditions, to put the code of a short function "in line" from the > places where it is called, rather than separately, thus removing the > (small) runtime function setup/teardown overhead. But that's an internal > detail and judgement-call made within an optimiser, not a user-visible > thing (unless one gets deep in there with "gdb" etc.). See the patch, I made it "static inline name()", "static name()" would be fine, too. Depends what the project likes more. Personally I prefer static inline, since it was a macro previously and inline should give the compiler a stronger hint to really inline it. -- Bernd Schubert Q-Leap Networks GmbH _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
_______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
