On 09/17/2013 10:54 AM, Tom Hacohen wrote: > 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
Not mine. > 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". Well, not everyone would like to be treated like you. :) > 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. Not happening here. >> >> 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. Stay on your side. >>>> 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). Thanks. I know that. I digged through code I never wanted to see to make a correct fix. >>>> 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. What makes you think this is an argument? It is a statement I made without arguing about the original problem anymore. You stated you want to see them and I feel we see but don't fix them so you have won the job doing it in my eyes. >> 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. Nah, I have anice big shelf with looser trophies. Full of things I gave up on. :) 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
