|Data migration email@example.com (shrey) (2006-04-03)|
|Re: Data migration DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-04-08)|
|Re: Data migration firstname.lastname@example.org (shrey) (2006-04-12)|
|From:||Hans-Peter Diettrich <DrDiettrich@compuserve.de>|
|Date:||8 Apr 2006 17:03:11 -0400|
|Posted-Date:||08 Apr 2006 17:03:11 EDT|
> As part of an experimental security project, I am looking at
> relocating data from one system to another. The code is interpretive
> and designed in an manner such that it work with the relocated data.
> Now we want to extend this to data some of which could be pointers.
> This in our case would require adjusting the values of the pointers.
> Basically, by first finding out what object is the pointer pointing to
> first and then using that to correct the value.
In my private dictionary <g> I use "reference" instead of "pointer",
when dealing exclusively with the base addresses of objects of a well
known type and size. In the case of references you can build a list of
all referenced objects, and replace every address by the list index of
the object. The objects can be emitted into the output stream as
required, or after the emission of the code, it's not necessary to
build a list of all objects in advance. The data of every object must
be packaged in a way, that allows the receiver to determine the begin
of every object, so that the index again can be replaced by the new
address of the object. At the receiver end you may create chains for
all references to the same object, so that you can correct (fixup) all
references as soon as the address of an object is known.
When the data objects also can contain references, you'll also have to
determine which data fields deserve fixups. This can be implemented by
adding general type information to the data objects, or by adding a
fixup list to every object, indicating which fields have to be treated
> Can anyone point me to references to anything similar?
IMO you want to *serialize* (or Windows: *marshal*) information, for
reuse later or in an different place.
> What kind of restrictions on language would be needed to make this possible
As indicated above, unrestricted pointers are not very handy, because
the amount of related data is unknown. Pointer arithmetic also should
not be used, because it would allow to reference any amount of data
before or after the address, currently held in a pointer. Also pointers
into data structures should not be allowed, because then you had to
figure out which pointers go into the same contiguous memory area, which
consequently had to be transmitted as a contiguous block of data, and
every address had to be transmitted as base/offset pair.
Return to the
Search the comp.compilers archives again.