Skip to content
This repository was archived by the owner on Sep 30, 2024. It is now read-only.
This repository was archived by the owner on Sep 30, 2024. It is now read-only.

Allow implicit conversions from pointers to unchecked arrays to pointers to checked arrays #20

@secure-sw-dev-bot

Description

@secure-sw-dev-bot

This issue was copied from checkedc/checkedc#20


Currently, checked arrays and unchecked arrays are distinct types. This will cause problems when passing a multi-dimensional unchecked array to a checked array parameter. Consider the following code:

void f(int checked arr[10][10]);

During type checking, arr is treated as a pointer to a 10-element checked integer array:

int (*arr) checked[10];

If we have code of the form:

int g() {
int myarr[10][10];
f(myarr);
}

Typechecking will fail. myarr will be converted to a pointer to an unchecked array.

int (*myarr)[10]

and the array types will not be compatible. Compatibility is a specific notion in the C Definition. It is problematic that typchecking fails because we know that that the actual size of data is sufficient.

I propose that we add an implicit conversion from pointers to unchecked arrays to pointers to checked arrays, where the only difference between the array types is whether the arrays are checked or unchecked. We will rely on the checking of bounds declaration to enforces that the pointer to an unchecked array points to a valid region of memory of sufficient size for the checked array.

This is actually a deeper change at the level of the C Definition. C only defines compatibility, which means roughly "two types are equivalent". C does not have a notion of "assignment compatibility" that differentiates between source and destination types. With bounds checking, assignment compatibility arises naturally. It is OK to pass an array of T with more elements than expected to a function. It is also OK to pass an unchecked array (of sufficient runtime size) to a checked array as well. The reverse, though is not OK. This means that we need to have a "directional" notion of compatibility.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions