Re: Ball of string -> g_return_* macros in static functions - lots of them :(

[John Rice <John Rice Sun COM>]

Cool,

So what is the best way to help the maintainers fix this throughout the stack?

Recommendation to Maintainers:
Review your module - if g_return_* macros are being used in static private functions, either replace them with g_assert or normal if() tests on sight, depending on what the intent of the original check was.

Why:
Using g_returns_* to validate internal functions and external library api's prevents us from turning off these internal checks in production builds. This really hurts performance across the stack. Simply replacing the internal checks with g_asserts allows us to selectively turn them off these internal checks in production.
Using g_return_* in internal functions to check internal state, masks bugs [graceful failure instead of aborting] that we should be catching during debug, unless you specifically configure g_return_* to abort.


JR


For details see below.

http://developer.gnome.org/doc/guides/programming-guidelines/robust.html

See the "Assertions and Preconditions" section on that page.

Summary:  use g_return_*() in library entry points to ensure that no
garbage is fed into your library.  Use g_assert() internally to ensure
that you are in a consistent state.

Kalle Vahlman wrote:

2005/10/17, John Rice <John Rice sun com>:
  

 If they don't use g_assert then we have to turn off all the checking in the
library to get the performance gain, but now our external library calls
don't have any parameter validation in them :(
    

Oh, I misunderstood you. You are absolutely right, using asserts
internally is the Right Thing to do.

--
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
_______________________________________________
Performance-list mailing list
Performance-list gnome org
http://mail.gnome.org/mailman/listinfo/performance-list