When calling a vararg function in Scheme, a list is allocated for all arguments passed to the vararg parameter.
E.g., given a vararg function f
(define (f . x) x)
and a call to this function
(f 1 2 3)
a list of three elements is allocated and bound to parameter x of function f.
The pointer addresses allocated for the cons-cells of this list use the expressions of the corresponding arguments (in this case, the expressions 1, 2 and 3).
The problem arises when these expressions themselves allocate pointers, resulting in the same addresses being used for different allocations (therefore leading to an unnecessary and nonsensical loss of precision).
For instance, the result of the following expression
(car (f '(1) '(2) '(3)))
should just be '(1), while the result of our analyses is {'(1), 1}.
Unfortunately, this problem may occur more often than it seems, for instance because of (preluded) list-consuming vararg procedures such as append, list, map, ... .
Possible solutions for this issue include:
using something else than PtrAddr to allocate the list for the vararg parameter
using PtrAddr with other expressions (e.g., "fake"/dummy expressions wrapping around the original argument expressions) to allocate the list for the vararg parameter
When calling a vararg function in Scheme, a list is allocated for all arguments passed to the vararg parameter. E.g., given a vararg function
fand a call to this function
a list of three elements is allocated and bound to parameter
xof functionf. The pointer addresses allocated for the cons-cells of this list use the expressions of the corresponding arguments (in this case, the expressions1,2and3).The problem arises when these expressions themselves allocate pointers, resulting in the same addresses being used for different allocations (therefore leading to an unnecessary and nonsensical loss of precision).
For instance, the result of the following expression
should just be
'(1), while the result of our analyses is{'(1), 1}. Unfortunately, this problem may occur more often than it seems, for instance because of (preluded) list-consuming vararg procedures such asappend,list,map, ... .Possible solutions for this issue include:
PtrAddrto allocate the list for the vararg parameterPtrAddrwith other expressions (e.g., "fake"/dummy expressions wrapping around the original argument expressions) to allocate the list for the vararg parameter