Re: Question about NSRange on the G5 and the future sizeof(int).
Re: Question about NSRange on the G5 and the future sizeof(int).
- Subject: Re: Question about NSRange on the G5 and the future sizeof(int).
- From: James Quick <email@hidden>
- Date: Sun, 13 Jul 2003 13:13:11 -0400
On Sunday, July 13, 2003, at 12:18 PM, Shawn Erickson wrote:
On Sunday, July 13, 2003, at 07:36 AM, James Quick wrote:
In both Panther and Jaguar, the NSRange structure elements,
'location' and 'length',
are of type unsigned int. I am considering the use of NSRange to
build a
database of locations in a runtime image of an executable. On G3 and
G4
architectures this will be correct. What about the G5? Will an
unsigned int
be able to handle sizeof(aPointer)?
It would be risky to stick a memory pointer into the location part of
the range, also that goes against what NSRange is really about.
NRRange is to store an index and length from that index not a pointer
to something in RAM directly. I doubt NSRange will be changed to have
64 bit location (or length) any time soon, unless Apple releases a
complete duplicate 64 bit version of all frameworks.
I would consider making your own structure that used void* or look
around for a CF layer one that may do what you want.
NSRange is the perfect analogue for what I require, so I want to avoid
having to duplicate
all its functionality. The addresses I will store are not intended to
be used as a storage mechanism
but to model the structure of a running program. What better
description of an executable in
memory but a set of nested ranges? Memory segments, sections, modules,
methods/procedures,
source code lines. With debugging symbols present, nlist stabs entries
provide a map of (possibly
relative) locations in the currently mapped sections of memory, to the
elements defined in the
source code from which the modules were built. It is a perfect match.
Perhaps a better question is not about NSRange directly but about the
future of MachO objects
and nlist definitions. The relevant, panther include files seem not to
have changed, leading to the
assumption that, for the near future, the space occupied by libraries
and modules is still 4GB.
dyld.h, loader.h, nlist.h, stabs.h, all seem to support this conjecture.
If I can avoid re-inventing this wheel over the next 2 years I would be
ecstatic.
I would love to have an email address for someone at Apple who knows
about this stuff.
I promise not to take much of their time....
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.