On Thu, 19 Jan 2012 13:30:31 +0200 Tom Hacohen <[email protected]> wrote:
> On 19/01/12 12:29, David Seikel wrote: > > You just broke API. Those %y1 and friends in the strings used by > > the _elua_scan_params() and _elua_ret() functions are the names of > > Lua arguments and return values. The Lua scripts expect to have > > these names as table fields when calling these functions. As such, > > they don't clash with any posix functions, as the names are local > > to the tables, and Lua does not use posix names anyway. But the Lua > > side does expect these names to be used, so you just broke the API. > > > > Also note that you may now be clashing with yy* names in lexers and > > yaccers. > > I'm sorry. :(( Please revert my patch. > > > > In this case, all these variables are LOCAL, so how can they clash > > with any posix name that's not being used anyway? > > y1 is a posix math function that's included by math.h. Using y1 thus > triggers a shadow warning (which is something we want to know about. > Use -Wshadow). > > So y1 shadows a local declaration. If you can fine tune fix it so > it'll keep the API but not shadow variables, that would be great. 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. 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. 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. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
