[libeio] Patch / Addition of eio_mkstemp, eio_realpath, eio_access
Hi all, 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: - mkstemp — I have an implementation of this already working on top of eio_custom, but it'd be good to see it in the library itself. - realpath or canonicalize_file_name — I don't currently have an implementation of this, although, it shouldn't be too hard to implement. - 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). 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? Thanks Micheil Smith ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Fri, Feb 19, 2010 at 07:14:28PM +0100, Alejandro Mery am...@geeks.cl wrote: ok, simple test case. (yes, it's only warnings, but they distract a LOT) Really, this has nothing to do with libev - you found a buggy warning in your compiler, report this against your compiler, or switch it off. What's so difficult about it? Libev cannot and will not care about the many versions of compilers that generate bogus warnings, just as thousands of other software packages will not - this is an issue in your compiler, or your flags. -- 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 9:41 AM, Brandon Black blbl...@gmail.com wrote: I've seen this strict-aliasing issues with libev + gcc 4.4 as well. I haven't bothered to report it yet simply because I haven't had the time to sort out exactly what's going on, and whether it's a real issue that needs to be fixed, or as you've said, just an annoying bogus warning. The newer versions of gcc are very aggressive about aliasing assumptions for optimization, and my hunch is that this is a real issue with newer gcc's that really care about strict aliasing, but it's just a hunch at this point. I plan at some point in the next few days to dig into this in detail and sort it out for sure one way or the other. I meant to add (but forgot): if anyone is really worried this could cause a bug in your code in the short term, you can simply use -fno-strict-aliasing when compiling libev, which will prevent the compiler from making any bad aliasing assumptions about libev code. ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
I did look at those strict aliasing warnings a while back. It seemed to me that they're not bugs. They're caused by the header declaring structures (specifically ev_* and ev_watcher) that start with some common elements, casting a pointer to one to a pointer top the other, and accessing the common 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 that isn't likely to happen on any real system (which has abi rules so different compilers can interoperate). In theory, one could avoid these warnings by having the larger structures have the smaller structures as their first member, not just sharing their first members, but that might make the code uglier and is not worth imo. (The strange thing is that in some places the ev.h header actually has code to silence these same warnings, such as in the ev_init macro.) The warnings are a bit annoying because they appear in user code that expand macros from the ev.h header, and with gcc they were not specific enough for me to easily tell that these are indeed caused by the header doing these casts, not something in my code. 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 -- I don't quite understand the rules, but then I don't understand the rules that allow the double meaning of std::clog either. Ambrus ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
