wrong type for `PfnDebugReportCallbackEXT`?

[andrewrk]

 pub const PfnDebugReportCallbackEXT = ?*const fn (
     flags: DebugReportFlagsEXT,
     object_type: DebugReportObjectTypeEXT,
     object: u64,
     location: usize,
     message_code: i32,
     p_layer_prefix: ?*const u8,
-    p_message: ?*const u8,
+    p_message: [*:0]const u8,
     p_user_data: ?*anyopaque,
 ) callconv(vulkan_call_conv) Bool32;

According to https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/PFN_vkDebugReportCallbackEXT.html:

pMessage is a null-terminated UTF-8 string detailing the trigger conditions. pMessage is only valid for the duration of the callback.

[Snektron]

The spec is not descriptive enough for this: for structures each member is wrapped in a tag, and for commands, but nothing like that exists for the fuction pointers and implementations are left in the dark:

         <type category="funcpointer">typedef VkBool32 (VKAPI_PTR *<name>PFN_vkDebugReportCallbackEXT</name>)(
     <type>VkDebugReportFlagsEXT</type>                       flags,
     <type>VkDebugReportObjectTypeEXT</type>                  objectType,
     <type>uint64_t</type>                                    object,
     <type>size_t</type>                                      location,
     <type>int32_t</type>                                     messageCode,
     const <type>char</type>*                                 pLayerPrefix,
      const <type>char</type>*                                 pMessage,
     <type>void</type>*                                       pUserData);</type>

We can probably hardcode in the generator that char* will always be a [0:*]const u8 for now. It would be nice if the spec wasnt hyper optimized for C, though

[andrewrk]

I see. I suppose the other option here would be a set of overrides on top of the provided data.

[Snektron]

Yep, some parts are already handled like that. Ideally I'd get it fixed in the spec.