On 17/09/13 10:40, Stefan Schmidt wrote: > 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. :)
I actually do it on purpose. By default thunderbird replies to list, I have to explicitly choose reply to all. I do that because that's how I'd like to be treated as well. I'm replying to you in specific with everyone to hear, hence you are in the "To" and everyone is in "cc". It has the additional bonus, that for most people it gets to their inbox instead of the ML dir, which is as expected (in my pov) when replying directly. > > 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. :) Well, both common-sense (according to David that might not apply to gcc), and the gcc manual are on my side on this one. > >>> >>> 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 used to do it a lot, and I'll do it still if I find anything obvious. The problem is, I don't want to silence warnings, I want warnings to be fixed. Usually, that means spending a lot of time on code you are not familiar with (e.g the Evas_GL code). > >>> 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. :) That's hardly an argument for or against anything. > > 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. I think you are meant to lock such things in the drawer, like laptops, cellphones, your mouse and your desktop's hard-drive. -- Tom. ------------------------------------------------------------------------------ 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
