Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
alloca: track alloca()ed allocations
This introduces a DT_IDFLG_ALLOCA flag which, when set, will (in future commits) cause integer variable setting to subtract the address of the scratch base from the assignee before assignment, variable fetching to add it, and dereferences to bounds-check it. There is a matching parse tree node flag DT_NF_ALLOCA which indicates that a parse tree node has been influenced by an alloca'ed value. There is also a DT_IDFLG_NONALLOCA flag which indicates that an assignment happened that did *not* involve an alloca()ed value: this will be used to prevent reuse of the same variable for both alloca() and non-alloca() purposes. The node flag propagates across most operations (but not dereferences, because dereferencing a pointer yields a value, which should not have its offset adjusted). One function's identifier has this flag set by default: obviously enough, alloca(). (Other functions that always return alloca()ed pointers, or pointers into alloca()ed space, should do the same.) Propagating this is fairly amusing, because not only do we have to handle propagation of these flags both to and from parse tree nodes and identifiers (because you can do things like "foo = alloca(10); bar = foo;") and across casts, but we have to handle cases like identifiers with alloca'ed vars in their arglists (which will become relevant when indexed associative arrays appear), ternaries in which one side is allocaed and the other side isn't (which flips on a similarly-propagated DT_NF_NONASSIGN flag to stop you using such things in assignments), and the same possibility of changes sweeping backwards and forwards between the predicate and the clause that already has to be handled for ++, which can require the two to be cooked in either order and to be cooked repeatedly (yes, you can alloca in a predicate, and you can use alloca'ed memory in a predicate). A few things are newly banned that were allowed before: in particular, you can't say bar : -alloca(10). It makes little sense to negate a pointer anyway, but this pointer's eventual representation as a bounds-checked offset from the scratchmem array makes it even less sensible. You also cannot add or subtract pointers where one is allocaed and the other is not, nor (as noted above) assign the results of a partly-allocaed ternary to a variable. The parser dn_flags is boosted to a ushort because we have run out of flags :( Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com>
- Loading branch information