On 19/01/12 14:30, David Seikel wrote: > Well, the API names don't clash at all, since on the C side they only > appear inside strings. The Lua side does not have posix, and the API > names are namespaced in tables anyway, so no clash there either. > Though there is a posix library for Lua, we sandbox away the function > needed to actually load it, and it will be namespaced in it's own posix > table. So either way, we can happily use y1 on the Lua side with no > fear.
As you can see, I did the foolish mistake of doing a search and replace without paying too much attention. > > On the C side, it's only a real problem if we want to actually use this > mysterious y1 function inside those functions where it's being used as > a local variable. From memory, we don't actually use ANY of the math.h > functions in that entire file. We are certainly not using Bessel > functions. The only reason it's at all a problem is coz we include > edje_private.h, which includes Edje.h, which includes math.h. It's not > a real problem, we are just shutting up the compiler when we tell it to > be paranoid about such things. > > On top of that, according to man 3 y1, that function requires feature > test macros that we don't explicitly turn on. Perhaps somewhere deep > inside one of the other include files it's getting turned on? > > I'm already compiling with -Wall, and -Wextra. What part of "all" does > GNU not understand? Turning on -Wshadow tells me that we are also > shadowing "index" from strings.h. Now we can continue to be paranoid > about such things, and find that all the good names are already taken > by standard libraries, and hope that a standard library we somehow > manage to include on some other platform does not cause shadow > "problems".. Or we can do the sane thing, not be paranoid, and don't > worry about shadowing useful names like "index" and "y1" when we don't > actually need the stuff we are shadowing. > > After all, the only time it's a real problem is if we actually want to > use those names we are shadowing, in which case it becomes obvious we > need to change our local variable names. So if I ever use Bessel > functions in edje Lua, I'll worry about shadowing y1. Until then, it's > just silly paranoia. > There's another big reason for using shadow warnings and that's removing variables, I almost dismissed this reason myself, but luckily Gustavo set me straight. For example, lets assume you wrote a piece of code that uses a local variable called index. After a while you decide to refactor the code and consequentially you remove the local declaration of index. Because you previously shadowed a declaration, the current usages of the variable index are still legal (although you removed the relevant local declaration) and the code will depend on uninitialized/unrelated values. > I seem to remember a discussion about why we don't turn on things like > -Wall by default, I can't remember why, but I guess that this sort of > useless paranoia might have been the reason. Nope, the reason we do it is because raster doesn't want to set people's CFLAGS and LDFLAGS at all. -- Tom. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
