Re: convert CFRange to NSRange?
Re: convert CFRange to NSRange?
- Subject: Re: convert CFRange to NSRange?
- From: John Engelhart <email@hidden>
- Date: Mon, 13 Dec 2010 03:59:48 -0500
On Sun, Dec 12, 2010 at 11:51 AM, Andreas Grosam <email@hidden>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 (email@hidden)
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:
This email sent to email@hidden