Re: [PATCH 2] fix broken strict aliasing
On Sat, Feb 20, 2010 at 09:41:35AM -0600, Brandon Black blbl...@gmail.com wrote: I've seen this strict-aliasing issues with libev + gcc 4.4 as well. I You say to have seen strict aliasing issues, but none have been reported so far. Care to actually come up with the issues you have or think to have? There are currently no known strict aliasing issues. Making them up out of the air doesn't really count. All this is so far is a major time waster for everybody. Facts please... -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Sat, Feb 20, 2010 at 06:20:26PM +0100, Zsbán Ambrus amb...@math.bme.hu wrote: elements that way. The compiler warns about that because the C standard doesn't guarantee that the rest of the elements of the struct doesn't change how the first elements are laid out in the struct, but To the contrary, the C standard guarantees just that, and gcc follows it. Seearch for common initial sequence. Think about it, if the C standard didn't make that guarantee, unions would be mostly useless. Don't make so certain statements about the C standard if you don't really know it - you are doing a disservice to anybody else who might be stupid enough to blindly believe you. (Sorry to be so explicit, but I get really annoyed when people argue with made-up arguments like yours - check your facts, this is easy enough to google). that isn't likely to happen on any real system (which has abi rules so different compilers can interoperate). In theory, one could avoid It cannot happen on any system, real or theoretic, as long as it implements C. Incidentally, what bothers me more than these aliasing warnings is that there's both a structure called struct ev_loop and a function called ev_loop in the same header. Apparently C++ does allow this -- C allows it as well of course. I am not swure what others you, but the struct tag namespace and the function identifier namespace are distinct in both languages, and have been that way forever. Of course, if standard C (or C++) bothers you, maybe you could interest yourself with the perl interface, which has simpler scoping rules, albeit Perl has never been standardised. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [libeio] Patch / Addition of eio_mkstemp, eio_realpath, eio_access
On Sat, Feb 20, 2010 at 07:35:25PM +1100, Micheil Smith mich...@brandedcode.com wrote: Hi all, First, please format your e-mail in a readable way when taking part in public discussions. Making your e-mails hard to read for others will make them less inclined to read or reply to them, I've recently been doing work with the node.js project, and I've been updating their filesystem module to support a lot more of the functionality that lbeio provides. I have come across a few cases where libeio doesn't provide something that may be really useful, these cases are: libeio tries to provide basic functionality. mkstemp is easily replicated, realpath is not very portable and access is really useless and shouldn't be used in new code. on top of that, these are commonly implemented in userspace and take a lot of stackspace, which libeio doesn't provide. so right now, I am not so inclined to include them. as you pointed out, if you really need them, then eio_custom should work. - access — I also don't have an implementation of this, but the use case is for this is to check if a file is readable / writable / executable by the process's uid/gid (If I'm understanding the documentation on it correctly). yes, and specifically not according to the effective uid/gid, which causes a number of security issues. it also isn't very reliable. if you want to know whether you can open a file, open it. I'd be willing to try and implement patches for these, although, I haven't done a heap of C++ before. Would these methods be considered for inclusion in libeio? well, libeio is written in C of course, so the patches would have to be in C. right now, I'd like to have a compelling argument for those functions, that are strong enough to withstand the potential portability issues libeio runs into them, and why they really have to be done as part of libeio. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On 02/20/2010 04:06 PM, Marc Lehmann wrote: Making things up doesn't make them true - do you really think this will help your credibility? This and other compiler bugs have been discussed in the past and are even discussed to some extent in the documentation. Why you think you need to bring this up in this way, without presenting any new evidence and by blatant attempts at bullshitting escapes me. I had been burnt quite severely one time with openssl and powerpc, thus I'm a bit touchy about such issues, I'll doublecheck what the actual macros are doing. You surely have a better knowledge than me about where those macros are located and what they do, please check them as well. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
