On Tue, Sep 7, 2010 at 4:36 AM, Brett Nash <n...@nash.id.au> wrote: > Hello All, > > I'm proposing we remove all the EINA_ARG_NOTNULLs floating around in > public headers. > In short they may generate a warning, but they subvert any checks we > have in the API, and can cause valid code to break. > > The not null macro expands to the GCC attribute "notnull". From the GCC > documentation[1]: > "The compiler may also choose to make optimizations based on the > knowledge that certain function arguments will not be null." > > This means (with optimisations on) that GCC will remove any calls of the > form > if (arg == NULL) return err; > Because you have told it that arg will NEVER be NULL. > > But we don't make that guarantee at all. Instead we say that people > calling this function MAY get a warning if they pass a NULL pointer. > > So we cripple all our magic checks. > > Hence we really should kill the not nulls, they don't do what we want, > they may give us a small performance boost, but at the unacceptably high > cost of generating broken code.
First, our checks marked as NONNULL should actually not be NULL, so although now we don't crash, people shouldn't rely on it as later on, due optimizations we may remove these checks altogether. However we noticed loooooong ago what you said, and that's why we "fixed" it: when you're processing the unit with such function definition you include eina_safety_checks.h and it will redefine such macro to void. In that case the compiler will not know that the function parameter may never be null and will keep the check. Actually this is required to get the logging you see in libraries done right (check eina itself). In eina_safety_checks.h we have some documentation about that usage. If it is not clear then please help fixing it. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
