KhronosGroup
Inconsistent word breaks in enum XrSceneMarkerQRCodeSymbolTypeMSFT
The enum entry XR_SCENE_MARKER_QRCODE_SYMBOL_TYPE_MAX_ENUM_MSFT separates "QRCODE" differently to the other entries in this enum. QRCODE vs QR_CODE
Better would be to use the symbol XR_SCENE_MARKER_QR_CODE_SYMBOL_TYPE_MAX_ENUM_MSFT, with an additional _
from openxr.h:
typedef enum XrSceneMarkerQRCodeSymbolTypeMSFT {
XR_SCENE_MARKER_QR_CODE_SYMBOL_TYPE_QR_CODE_MSFT = 1,
XR_SCENE_MARKER_QR_CODE_SYMBOL_TYPE_MICRO_QR_CODE_MSFT = 2,
XR_SCENE_MARKER_QRCODE_SYMBOL_TYPE_MAX_ENUM_MSFT = 0x7FFFFFFF
} XrSceneMarkerQRCodeSymbolTypeMSFT;
An issue (number 2227) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2227 ), to facilitate working group processes.
This GitHub issue will continue to be the main site of discussion.
By the way, a different vendor recently added other weirdly named "max enum" symbols, including XR_FACE_CONFIDENCE_2FB_MAX_ENUM_FB XR_FACE_EXPRESSION_SET_2FB_MAX_ENUM_FB XR_FACE_TRACKING_DATA_SOURCE_2FB_MAX_ENUM_FB XR_FACE_CONFIDENCE_2FB_MAX_ENUM_FB
The _2FB_MAX substring should instead read 2_MAX to be consistent with its sister enum values.
Yeah that is a known bug in the scripts at this point. However that vendor had shipped their implementation with headers containing the same error so resolving it was not critical. In any case, those values are not intended for actual use: they only exist so that C will make our enums the right size.
