Skip to content

new (mutable unboxed vector) hands the user uninitialized memory #30

@rwbarton

Description

@rwbarton

I don't think it should be the default behavior in a managed language to provide access to uninitialized memory. Aside from potential security issues, it also means that computations using mutable unboxed vectors in ST are nondeterministic. At the very least, this behavior should be clearly documented!

Naturally some applications need uninitialized arrays. I would suggest repurposing the name unsafeNew for this (the current unsafeNew is silly—I can't imagine any application for skipping the bounds check of an allocation), or using a new name like newUninitialized.

The same comments apply to grow and unsafeGrow.

For comparison, the array package has a newArray with an extra argument which is used as the initial value of every entry of the new mutable array, and a newArray_ which (for unboxed arrays) produces an uninitialized array when used in IO, and an array initialized to a fixed value (depending on the type) when used in ST.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions