`Scope` provides a mean of performing uninitialized scoped allocations
on the JS stack.
This can generally be unsafe as this form of allocation temporarily
leaves an element representing garbage memory on the JS stack, which
could be accessed by other parts of the program.
Indeed, a set of bugs related to this kind of behavior was recently
solved.
Hence, to reduce the surface of those kind of bugs, the usages of
uninitialized scoped allocations were reduced to a minimum.
The solution to the recent set of bugs related to uninitialized scoped
allocations introduced a series of `construct` methods that ensure that
the uninitialized allocation and the initialization of the allocated
elements are performed as a single step of computation, reducing the
surface for incorrect usages of those kind of allocations.
The solution was expanded by the introduction of new `construct` methods
that cover initialization from other types and some different means of
initialization that were used around the code-base to work with
uninitialized scoped allocations.
Similarly, the various allocation methods in `Scope` were subsumed by
the new `construct` methods, with the only remaining means of allocation
being the uninitialized one that is used as a building block for the
`construct` methods.
In particular, `Scope` provided three forms of allocation under the
various `alloc` methods.
The aforementioned uninitialized allocation and an allocation that
performed initialization to either the Undefined or the Empty value.
The latter two forms of allocation were converted to forms of
`construct`.
Since they directly map to the same concept of allocation plus
initialization, the conversion avoids having two names for the same
concept.
More specifically, the form of allocation that initialized to the
Undefined value was converted to the new `constructUndefined` which
keeps the same behavior.
The different naming from the basic `construct` methods is justified by
the different interface, which doesn't require choosing a initial value,
and the different implementation which is built on the more general
`construct` methods rather than the lower level allocation routines.
The form of allocation that initialized to the Empty value was removed
as it was found to be unused in the code-base.
The converted allocation methods generally provides the same interface
and behavior with the exception of always requiring the user to specify
the amount of allocate objects.
This is a change compared to the previous interface which allowed a
zero-argument version that allocated a single element.
The writer of the patch considered the additional terseness
inconsequential compared to the required additional code so that the
possibility was not preserved.
The code related to the converted allocation forms was removed as a
consequence of the conversion.
The remaining uninitialized allocation form was made private, to avoid
general usage outside of `Scope`, and favoring usages of the substitute
`construct` methods.
A comment that was related to usages of uninitialized scoped allocations
was moved to the lower level `jsAlloca`, which forms the basis for those
allocations and creates the abovementioned issues, where it was expanded
upon.
Usages of the non-uninitialized allocation forms around the code-base
were modified to use the new `constructUndefined` method.
Most usages of the uninitialized allocation form were modified to use
the new `construct` methods that were added to replace them.
Exceptions were made for those cases where the initialization routine is
either very complex or depends on details that shouldn't belong to
`Scope` such that they cannot be trivially encapsulated in a `construct`
method.
Instead, the relevant function or object was friended by `Scope` to
allow accesses to the now private form of allocation.
Those usages were previously checked and are supposed to be safe but
should be scrutinized if they are modified or the code around them is
modified.
One of the friended functions, `callDatafromJs`, previously offered a
default argument that was not made use of in the code-base.
The default value for the argument was removed to simplify friending the
function, considering the difficulty the language has with friended
function with default arguments and considering that it would have
required the default value to be moved out of the function definition
into a forward declaration in the unrelated header that defines `Scope`.
It is expected that the changes will reduce the surface of usage of
uninitialized scoped allocations in favor of a slightly safer approach,
make the issue that those usages can produce more apparent and generally
centralize the usages as much as possible to make them easier to
evaluate and keep track of.
Change-Id: I351329f2c139201e0728791df6da297698170f55
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>