(repost, tried sending it a few hours ago and it hasn't gone through for some reason)
Hey, Daniel and I are back to hacking on Eolian and we've again reached the topic of nullability. In most correct cases, C pointers either point to a valid memory region, or hold NULL. While NULL is valid for many APIs, it's not valid in others (strlen() and etc.). I can think of three examples of NULL in API: 1. Pointers for multiple return values - size_get(&w, NULL), the second one is an optional return value. 2. NULL is a valid value: part_text_set(NULL, "some text"), the NULL means "use default". 3. NULL is not allowed: strlen(). For 1 we suggest having @optional, which indicates optional values (similar to what they do in gobject land). For 2 we suggest @nullable, indicating null is a valid value. And 3 is the default. This works great, until you consider that in EFL land, we like using EINA_ARG_NONNULL(). EINA_ARG_NONNULL() is a macro for decorating function parameters, and is actually a wrapper around a gcc attribute "nonnull". This attribute is great because it decorates the parameters in ways that can help static analysers understand our code and find error cases, and adds compiler warnings for obvious things (like passing NULL). However, the problem with this attribute is that according to the GCC manual: "The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null."[1] Which means it's possible it'll remove our runtime checks, which is a price we are not willing to pay. This essentially means that decorating our API with this is dangerous and should be avoided. This notion is not new, this is something we've discussed in the past, and I think now that we are cleaning the why we define our API, it's time to mention it again. This attribute is not safe and should be avoided. Bottom line, I'd like us to stop using EINA_ARG_NONULL, and to inform you we plan on not using it in generated Eolian headers any more. I'm sending this email because I'd like to see what you think about the suggestion for eolian (@optional and @nullable) and the idea of dropping EINA_ARG_NONULL given that it's unsafe and can result in removed safety checks. No need to reply with +1, I don't care for votes of support, only arguments against (and arguments for if arguments against are raised). We are going to implement @optional and @nullable anyway (can be removed if someone finds them stupid), so it's mostly about the nonnull part. Thanks, Tom. Reference: [1] https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
