Skip to content

Conversation

@umar456
Copy link
Member

@umar456 umar456 commented Jun 10, 2022

Some of the ArrayFire constructors that accept the dim_t type are not
marked explicit. this allows the initialization of the ArrayFire's array
using integer types.

Description

Some of the ArrayFire constructors that accept the dim_t type are not
marked explicit. this allows the initialization of the ArrayFire's array
using integer types. For example

af::array a = 5

will create an af::array with 5 elements. This is not intended behavior.

I have looked into the ABI for this change and it doesn't seem to
be affected on GCC. I have to still test this on MSVC. This CAN
break some existing code because it does change the API but ArrayFire
was never designed with this code in mind.

Changes to Users

This change CAN break some user code. The following code will break

  • Initialize af::array using an integer or float
array a = 5;
array b = 5.0;
  • Pass an integer to a function that accepts an array
void func(af::array a) {
    ...
}

func(5);

Checklist

  • Rebased on latest master
  • Code compiles
  • Tests pass
  • [ ] Functions added to unified API
  • [ ] Functions documented

Some of the ArrayFire constructors that accept the dim_t type are not
marked explicit. this allows the initialization of the ArrayFire's array
using integer types. For example

```
af::array a = 5
```

will create an af::array with 5 elements. This is not intended behavior.

I have looked into the ABI for this change and it doesn't seem to
be affected on GCC. I have to still test this on MSVC. This CAN
break some existing code because it does change the API but ArrayFire
was never designed with this code in mind.
@umar456 umar456 merged commit be7f2d9 into arrayfire:master Sep 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants