On Wed, May 23, 2012 at 5:40 AM, Bluezery <[email protected]> wrote: > 2012/5/22 Cedric BAIL <[email protected]>: >> On Tue, May 22, 2012 at 12:48 PM, Christopher Michael >> <[email protected]> wrote: >>> On 05/21/12 16:34, Sebastian Dransfeld wrote: >>>> On 05/21/2012 08:24 AM, Bluezery wrote: >>>>> Hello, >>>>> >>>>> Some efreet APIs do not check input parameters. So I add checking by >>>>> using EINA_SAFETY_ON_XXX(). >>>>> ISO/IEC statndards says that "If an argument to a function has an >>>>> invalid value, behavior is undefined" . But this is just for the >>>>> primitive functions such as libc. I think that parameter checking is >>>>> needed in at least EFL exported APIs >>> >>> This I 150% support (Not the use of Eina, but rather the checking) !! >>> Exported APIs need to be clean.... >>> >>> EFL needs lots of param checking. Has been missing for a bit of time >>> now. I try to add it as I go, but not everyone is supportive. Some do >>> see it as a "wasted variable check" ... but I would rather KNOW that the >>> stuff I am working with IS valid first, before I start to work with it >>> ;) ... If not, then what's left ? A Guess that the variable is valid ??? >>> No thanks ;) >> >> Actually the EINA_SAFETY is something that could be turned off at >> build time, so the cost at runtime would be zero on a production >> build. This also means that if you use EINA_SAFETY, apps will be >> warned about there unwise usage. Prefer direct check if you want them >> to always work. I do consider that for example *_free(*) should always >> work on NULL, so better to not use EINA_SAFETY. >> Sorry I don't have much time to check your patch now. Maybe will do next >> week. >> -- >> Cedric BAIL > > Thank you for your comment. > In release time, we can also disable logging?? but if so, some > overhead is remained yet. > Currently it seems that we can only enable/disable eina safety checks in eina > Can we add another safety check mode to reduce overhead more such as > safety check without logging mode (only use if/else)?? and we can > select safety check mode when build time. > It seems that current IT trend makes release cycle more shorter > (incremental releases) and logging system may be needed after a > product is released in this case.
You can disable it in whatever software defines the maximum logging level. If you choose to disable in your own project, just do look at expected CPP symbol: EINA_LOG_LEVEL_MAXIMUM What I recommend is to only do EINA_LOG_LEVEL_MAXIMUM=1 (error) and that will disable the report of all but critical and errors. Warning, debug and info are gone at compile phase if you choose -O2 (maybe -O1 as well). As reference see: - http://trac.enlightenment.org/e/browser/trunk/eina/configure.ac#L175 - http://trac.enlightenment.org/e/browser/trunk/ecore/configure.ac#L78 That's for logging, but safety check logs to ERR (1) and would be still be printed. You can opt to decrease the maximum log level, keeping the "if() return" without the logging. Right now there is no way to disable the safety checks for the user software as it's configured only in eina_config.h But it's pretty easy to add such check in eina_safety_checks.h, allowing user software to define some EINA_SAFETY_CHECKS_DISABLE. But really, the check is pretty irrelevant... if you consider the cost of a comparison instruction it's way smaller than a function call, that we do a lot. Usually these checks exist only on function entrance and not on hot-paths. Then leave the safety checks and the benefit they may bring. You should decrease the maximum log level as it will also reduce the code size by removing the unused strings. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
