Pointer data stored in IDL SAVE files are particularly difficult to manage, because the actual heap variables are stored in separate records which precede the record of interest. Thus, if your application requires the reading of pointer data, you must perform special processing in your own code in order to support it. In essence, you must maintain an inventory of heap variables as they are encountered in the file.
If these procedures are not followed then pointer data will not be read, and a LONG integer value appears in the pointers' places. Under IDL 4, pointer data can never be read.
This is accomplished by placing some additional logic in your file processing loop. There are four separate components to this: (1) loop initialization; (2) reading a HEAP_INDEX record; (3) parsing a HEAP_DATA record; and (4) passing extra arguments to CMSV_RDATA. The additional state information is maintained in two variables named PTR_INDEX, which keeps track of the heap variable numbers, and PTR_OFFSETS, which stores the file location of each variable.
ptr_index = [0L] ptr_offsets = [0L] ptr_data = [ptr_new()]
CMSV_RHEAP, block, pointer, index, unit=unit ptr_index = [ptr_index, index] ptr_offsets = [ptr_offsets, lonarr(n_elements(index))] ptr_data = [ptr_data, ptrarr(n_elements(index))]
opointer = pointer CMSV_RVTYPE, block, pointer, vindex, /heap, unit=unit vindex = floor(vindex(0)) wh = where(ptr_index EQ vindex) ptr_offsets(wh(0)) = offset + opointer
Keep in mind that the file offset is OFFSET+POINTER.
CMSV_RVTYPE, block, pointer, name, size, unit=unit, template=tp CMSV_RDATA, block, pointer, size, data, template=tp, $ unit=unit, ptr_offsets=ptr_offsets, $ ptr_index=ptr_index, ptr_data=ptr_data
If this technique is used properly, only those heap variables
which are needed are read. Thus, there are never any lost or
dangling pointers. Since each bit of heap data is stored in a
variable returned to the user, it is not necessary to
PTR_FREE(ptr_data); in fact, doing so would corrupt the input