Hello. As you like to point out problems with mails. No need to CC me, I'm on the list. :)
I also know that thunderbird sucks at this but I'm able to do it. :) On 09/17/2013 10:21 AM, Tom Hacohen wrote: > On 17/09/13 08:30, Stefan Schmidt wrote: >> Hello. >> >> On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >>> devilhorns pushed a commit to branch master. >>> >>> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >>> Author: Chris Michael <cp.mich...@samsung.com> >>> Date: Mon Sep 16 11:40:30 2013 +0100 >>> >>> Remove __UNUSED__ from function declaration where parameter is >>> actually used. >> >> This brings an old topic back into my mind. >> >> Its not the first time we eagerly tagged parameters as unused because >> gcc warned about it and later started to use them without removing the >> unused label. This has the potential to screw us badly as it is up to >> the compiler to decide what to do with the parameter here. > > I don't know much about the exact implementation details of GCC, but I > find it very unlikely that GCC is allowed, or will ever actually do > anything about a *used* variable that is marked as unused. That just > sounds too crazy to be true. So I don't think we'll ever get screwed. I have in the back of my mind that we already screwed by this. I don't have the details at hand so I can't proof it. If I ever run into this problem with efl I will bill you the number of hours I had to work it out. Could easily be days for such a thing. :) >> >> Given how many callback and other signatures we have with user_data or >> other unused parameters we end up with 3630 EINA_UNUSED and even 71 >> __UNUSED__ in efl alone. All with the potential to be used at some point >> but forgotten to remove the label. > > Again, not really an issue. >> >> My proposal would be to use -Wno-unused-parameter in our CFLAGS to >> disable this warning and remove all EINA_UNUSED and __UNUSED__ from >> parameters. >> >> I know it has the downside that in the rare case where you add a >> parameter to a signature yourself (read: not using an existing function >> signature) you might add it and forgot to use it. Which will not >> reported as warning in this case. >> >> In my opinion the risk is higher than the benefit here. > > I disagree. I find this warning very useful when prototyping and > refactoring APIs (both internal and external). I would really hate > losing that in a mess of warnings. You just nominated yourself for fixing warnings to not have a mess of them. Congrats. :) >> I expect people to have a different opinion on this and get really angry >> if I just start to add the CFLAG and remove all EINA_UNSED from >> parameter so I thought I bring it up here to get some opinions. We >> normally have plenty of opinions around. :) > > I would definitely be angry. Not because I disagree with the whole > motion, but because it's one of those things that should be discussed > (so good job discussing). > > > We are already quite good with that. We used to be a bit better a while > back, unfortunately some people introduced new warnings. However, we are > still good. I think it's well worth to maintain this. As written above you won the job taking an eye on this. :) I will put this into the shelve with things I gave up on for EFL. Sitting next to a review-and-pull workflow, good commit messages and a sane coding style. regards Stefan Schmidt ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
