On Wed, Feb 24, 2010 at 8:15 AM, Marc Lehmann <schm...@schmorp.de> wrote: > On Tue, Feb 23, 2010 at 12:03:52PM -0600, Brandon Black <blbl...@gmail.com> > wrote: >> something I wanted to verify. I'm still not entirely clear, in the >> general case, when aliasing through pointers to technically-unrelated >> types (two different structs which just happen to have a common set of >> initial members, in this case) is allowed by the C standard, and when > > While that is nice of you, it has zero relevance to libev, as libev > doesn't alias those members at all (that's the whole point of the casts, > obviously...). > > It would be far more interesting to check whether any casts are missing, > causing gcc to not warn, but to actually alias, resulting in code > misoptimisations... > >> it does or doesn't cause gcc optimization bugs, which may or may not > > assuming aliasing where gcc doesn't does cause code not to behave as > intended. these are not optimisation bugs, but bugs in the code. > > afaics, if you remove the casts, gcc will actually "misoptimise" ev.c, > as this results in aliasing and gcc will happily ignore writes when > inlining...
What I am reading in your two responses above (feel free to berate me if I'm wrong) is that the way the ev.c code is now (the specific use of types and typecasts) both causes a gcc warning related to aliasing, and prevents an aliasing-related bug in the code (which would only manifest itself under optimization). Whereas if the casts were changed, the opposite would be true: no warning, but yes bug. You don't see why this is a confusing situation for users of gcc? My choices in this situation are seriously either get a warning or get a bug? >> be related to gcc's authors either not adhering to the standard, or >> being "more strict" about aliasing than the standard strictly >> requires. > > gcc is documented to be less strict than C, btw. Ok, so you're saying anything the C standard accepts in terms of legal aliasing, gcc will not mis-optimize? >> I'm taking you at your word that libev's pointer-aliasing doesn't > > Yeah, and you beating your wife is probably not a problem for the economy > either. > > As the very first I would like to see evidence for any aliasing in > libev. I have no clue what you are talking about, and so far, your statement > above is just more fud spreading... > > Really, if you don't know, why can't you for god's sake ASK instead of > making up bullshit claims such as libev doing any pointer aliasing (or > relying on any (obviously legal) aliasing in fact, e.g. by using memcpy). > > This continued assaults, intended or not, are really annoying. > > You are making up bullshit faster than I can set it right! > > I seriosuly suggets changing your strategy - don't make stupid statements you > have no clue about, ASK and I will answer. > > So far, all my time in this discussion is sucked up by just clarifying > all the weird statements people do, without having the slightets clue > apparently. > > If sth. is unclear, I can reply both by wearing my libev maintainer hat as > well as wearing my gcc maintainer hat. > > It is hard for me to help you if you don't have any questions and just > make fullmouthed but wrong claims. This is the kind of assault that makes our conversations almost unbearable. Unless I misunderstand you, the problem here is that I'm mis-using the word aliasing. You could have simply pointed out that I'm mis-using this technical term in this context, instead of ranting about false accusations. If I change the phrase "libev's pointer-aliasing" to "libev's specific method of using pointers to typeA to point to objects of typeB", then the second statement is true, and is what I meant. You do use ev_watcher pointers to refer to ev_io objects. If that isn't an instance of aliasing, then I'm mis-using the term. The mistake is that simple. I'm done with the rest of this. I think you know the answers to the questions I'm asking, but it's just not worth the abuse to figure out how to correctly ask you. -- Brandon _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
