Re: cast question, again
On Mon, Sep 29, 2008 at 3:58 AM, Marc Lehmann [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 02:00:20AM +0200, Alejandro Mery [EMAIL PROTECTED] wrote: I'm using -fno-strict-aliasing now to make gcc behave as a C compiler :) gcc tries to behave like a c compiler with or without that switch, that switch will not make any difference here. What you meant is that you made gcc accept your _buggy_, non-C code as if it were valid C, and try it's best to not misoptimise it, despite it having severe bugs. I know it's easy to deceive oneself, but the fact remains that your code is now buggy, thanks to the policy you are trying to follow. may I ask who's the buggy-code-maker from -Os -fno-strict-aliasing -Werror -Wall -W exactly? what do you suggest to add or remove to make gcc not produce buggy code? ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: cast question, again
On Sat, Sep 27, 2008 at 03:47:31PM +0200, Alejandro Mery [EMAIL PROTECTED] wrote: I'm have this issue too, compiling my project with -Werror -Wall -W (by policy) That's a pretty braindamaged policy: firstly, it means your compiler is no longer capable of compiling standard C, but only some badly-defined dialect of it, secondly, it means each compiler version will change the language you are working with. You may do that, of course, but you will not eb able to use libraries wirtten in standard C. warning: dereferencing type-punned pointer will break strict-aliasing rules and compiling stops.. but This is most likely a compiler bug - do you still get that with current versions of gcc? (self-timeout)-at = 0.0; (self-timeout)-repeat = (timeout); without the cast, compiles flawlessly. It compiles, and is broken, yes, as it allows the optimiser to drop your assigments now, as per ISO C language rules. The reason those warnings are warnings is that the compiler cannot know for sure. While some warnings are very solid, this warning has seen a lot of bugs in it's history, and is far from perfect, as is evident. (But this has been explained in other threads). there is any decent way to solve this? Easily, compile your project as standard C, the language libev was written in. Your mail is like I try to compile libev with my pascal compiler, but it gives me errors, how do I resolve that? and the answer is well, use a C compiler. This is so obvious I wonder why it comes up again and again. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: cast question, again
On Fri, Aug 29, 2008 at 05:11:23PM +0200, Egon Eckert [EMAIL PROTECTED] wrote: sorry about introducing the ever-appearing aliasing-warnings theme :)... Can someone, please, explain why *not* doing the cast in following macro definition: not doing the cast accesses the at member of *ev (with unknown type, but usually the type isn't ev_watcher_time), doing the cast accesses the at member of the ev_watcher_time struct overlaying whatever ev's real type is. since all the remaining code also accesses the ev_watcher_time.at, leaving out the cast allows the compiler to reorder code because can assume they are not the same lvalues. (in practise, this doesn't happen between source files yet, but it does happen within the same source file). In c++, one could use an explicit static cast to typecheck, but not in C. (in c++, of course, one could simply subclass...) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
