enum array output parameter validation of xrEnumerate functions is awkward

[pH5]

The xrEnumerateViewConfigurations valid usage section states:

Valid Usage (Implicit)

• If viewConfigurationTypeCapacityInput is not 0, viewConfigurationTypes must be a pointer to an array of viewConfigurationTypeCapacityInput XrViewConfigurationType values

Consequently, the core validation layer checks that all array members have a valid XrViewConfigurationType enum value before the function is called, even though viewConfigurationTypes is purely an output parameter. Since there is no enum value for an undefined / uninitialized view configuration type, the user has to awkwardly pick a valid value and initialize the array with that:

XrViewConfigurationType viewConfigurations[viewConfigurationCount];
for (uint32_t i = 0; i < viewConfigurationCount; i++) {
    viewConfigurations[i] = XR_VIEW_CONFIGURATION_TYPE_PRIMARY_STEREO;
}
result = xrEnumerateViewConfigurations(instance, systemId,
    viewConfigurationCount, &viewConfigurationCount, viewConfigurations);

This enforced initialization loop is confusing at best, especially if the runtime doesn't even support XR_VIEW_CONFIGURATION_TYPE_PRIMARY_STEREO. It would be better to allow passing an uninitialized or at least zero-initialized viewConfigurations array.

xrEnumerateReferenceSpaces has the same issue:

Valid Usage (Implicit)

• If spaceCapacityInput is not 0, spaces must be a pointer to an array of spaceCapacityInput XrReferenceSpaceType values

[rpavlik]

Good catch - looks like the valid usage generation (and validation layer generator) aren't paying attention to the fact that this is an output array of scalars. Output arrays of structs with type/next need their type/next initialized, but output arrays of scalars don't need to be initialized.

Although, on the other hand, it is true that it's a requirement on the runtime that all those values must be valid values - after the call. Maybe we just need to refine that generated validity.

cc @daveh-lunarg for validation layer

[rpavlik]

I have opened internal issue 1195 to track working group discussion on this.

[jherico]

FYI, this was fixed in the validation layer by KhronosGroup/OpenXR-SDK-Source#138

[rpavlik-bot]

An issue (number 1195) has been filed to correspond to this issue in the internal Khronos GitLab.

If you have a Khronos account, you can access that issue at KHR:openxr/openxr#1195.

[rpavlik-bot]

An issue (number 1195) has been filed to correspond to this issue in the internal Khronos GitLab.

If you have a Khronos account, you can access that issue at KHR:openxr/openxr#1195.

[rpavlik]

Fixed long ago, as noted.