On Sun, Dec 12, 2010 at 11:51 AM, Andreas Grosam <agro...@onlinehome.de>wrote:
> > On Dec 12, 2010, at 4:34 PM, Matt Neuburg wrote: > > > I feel like I'm missing something. I can't seem to typecast as CFRange to > an NSRange. > > Both are distinct C structs. In C, *explicitly* typecasting one pointer to > the other would be allowed but semantically incorrect. In C++ casting a > pointer to the other would be illegal. In C, *explicitly* typecasting one pointer to the other has been "undefined behavior" since at least C89. In C99, this was further clarified with explicit rules and behaviors so that compiler writers could take advantage of a simple form of type based alias analysis that, as a heuristic rule, tends to be "correct" 99% of the time in most C programs anyways. For practical purposes, C99 essentially makes the heuristic axiomatically "true". As a result, *explicitly* typecasting one pointer to the other with an optimizing C99 compiler significantly increases the odds that the optimized code generated will be subtly "wrong", at least in the sense that the unaware C programmer is likely to assume that the compiler is wrong and / or buggy. http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html http://en.wikipedia.org/wiki/Aliasing_(computing) Many people make the mistake that when C says something is "undefined behavior" it gives the compiler implementer / writer a free license to "fill in the details any way they want." Nothing could be further from the truth. The C standards have a different term for that- "implementation defined behavior", and a compiler writer is "required" to give the specific details of how their compiler deals with all of the "implementation defined behaviors" of the C standard. For example, http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/C-Implementation.html#C-Implementationdetails GCC 4.5.1's behavior. "undefined behavior" is actually short hand for something that could be paraphrased as "After 30 years of experience in writing C compilers, none of the people who actually write C compilers could come up with a good answer to this corner case. We couldn't even agree on a way on how to define that this behavior is explicitly forbidden, or even if it should be." In other words, "In theory, theory and practice are one and the same. In practice, they rarely are." Paradoxically, part of the power and utility of C is due to the fact that it has "undefined behavior" that is not explicitly "forbidden behavior". This lets an experienced C programmer "break the rules", with the tacit assumption that they understand every possible consequence of what "breaking the rules" means for this particular case. Unfortunately, even experienced C programmers have a tendency to assume that "pointer typecasting" means "stops the compiler from giving a warning". This is doubly dangerous when you typecast away const and volatile. Really, the only reason that "const" and "volatile" exist is for "optimizing" C compilers, and the C standard specifies behavior for "const" and "volatile" that in practice is only useful to the "optimizing" part of a C compiler. As part of the C99 "type based aliasing rules" (the part that made the heuristic that was true 99% of the time axiomatically true 100% of the time), another pointer qualification keyword was thrown in to the mix: "restrict". http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html So the take away answer is "Yes, you can pointer typecast. No, you should not pointer typecast." A ten second test you can give yourself to see if you sufficiently understand the issues involved to safely "break the 'no pointer typecasting' rule in C" is: "Have I written an optimizing C compiler that uses aliasing analysis as part of its optimization strategy?" If the answer is "No.", you are probably better off with the heuristic "I should not be pointer typecasting." > > I know I can pull a CFRange apart and reassemble it as an NSRange, but > shouldn't there be a simpler way? m. > > In fact, initializing a NSRange value from a CFRange value by means of a > library function would not be as easy as it might look at the first glance. > The reason is, CFRange has field members whose type is a *signed* long, and > NSRange field types are *unsigned* ints or *unsigned* longs (the size > depending on architecture). Mixing signed and unsigned types - possibly with > different bit-sizes - in a simple assignment operation would require > overflow checks and may require to throw exceptions. So, what should a > library function do? > > If required, you can include these checks in your code, though. > Now, I'll freely admit that I could be wrong here, but my quick back of the envelope, zero order approximation of the CFRange / NSRange problem being discussed suggests that for the set of architectures we are likely talking about (i.e., {i386, x86_64, ppc, ppc64, arm*}), I do not immediately see a corner case that manifests itself in a way that alters the code that is emitted. However, there are some very good reasons why the C standard does not allow one to "typecast a CFRange to a NSRange, and vice versa". Unfortunately, for the set of architectures listed, most of those reasons don't apply, which is probably why it looks like there shouldn't be a problem to the original poster. In reality, I think the original posters question is like one of those "famous job interview questions". It lets you quickly separate those who think they are C experts from those who aren't. Or, as Clifford Stoll infamously wrote in "The Cuckoos Egg"- ---------- In astronomy, you first enjoy three or four years of confusing classes, impossible problem sets, and sneers from the faculty. Having endured that, you're rewarded with an eight-hour written exam, with questions like: "How do you age-date meteorites using the elements Samarium and Neodymium?" If you survive, you win the great honor and pleasure of an oral exam by a panel of learned professors. I remember it vividly. Across a table, five profs. I'm frightened, trying to look casual as sweat drips down my face. But I'm keeping afloat: "I've managed to babble superficially, giving the illusion that I know something. Just a few more questions, I think, and they'll set me free. Then the examiner over at the end of the table - the guy with the twisted little smile - starts sharpening his pencil with a penknife. "I've got just one question, Cliff," he says, carving his way through the Ebherhard-Faber. "Why is the sky blue?" My mind is absolutely, profoundly blank. I have no idea. I look out the window at the sky with the primitive, uncomprehending wonder of a Neanderthal contemplating fire. I force myself to say something - anything. "Scattered light," I reply. "Uh, yeah, scattered sunlight." "Could you be more specific?" Well, words came from somewhere, out of some deep instinct of self-preservation. I babbled about the spectrum of sunlight, the upper atmosphere, and how light interacts with molecules of air. "Could you be more specific?" I'm describing how air molecules have dipole moments, the wave-particle duality of light, scribbling equations on the blackboard, and .. "Could you be more specific?" An hour later, I'm sweating hard. His simple question - a five-year-old's question - has drawn together oscillator theory, electricity and magnetism, thermodynamics, even quantum mechanics. Even in my miserable writhing, I admired the guy. ------ So, to the original poster- it's sort of like "Why is the sky blue?" There's actually a good answer, but it's unbelievably complex and convoluted. At the end of which you would understand both why it seems like you should be able to do it (and you might actually be able to "do it" on {i386, arm*, etc}), but despite this there are good reasons why you can't. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
