Checking for NULL and validity of OpenCL C types

This section https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#enqueuing-kernels contains the following wording

The macro CLK_NULL_EVENT refers to an invalid device event. The macro CLK_NULL_QUEUE refers to an invalid device queue.

The above implies it is expected to represent any invalid value of an object. However, I doubt it is even representable... i.e. there can be any random value that represents an invalid object but yet won't be CLK_NULL_EVENT or CLK_NULL_QUEUE (since it is expected to be a literal?). Here is one example of how incorrect kernel code can be written compliant with the current wording:

void foo(){
  clk_event_t e; // this has a random value from stack memory which is likely distinct from CLK_NULL_QUEUE.
  if (e==CLK_NULL_EVENT) // this will likely fail to detect invalid queue
    e = /* some code to initialize 'e' */;
  use(e); // function 'use' assumes that 'e' is valid but there is no guarantee to this.
}

If we compile this with clang we can see in the IR that a pointer that contains a random value is compared to -1 https://godbolt.org/z/dfcvd1hco

The translation to SPIR-V completely fails although it might be for a different reason: https://godbolt.org/z/34TovMxh3

So I wonder if we should correct the wording for NULL macros to something like:

The macro CLK_NULL_EVENT refers to an empty device event.

Use 'empty' instead of 'invalid' since there can be different values that are invalid.

Then macros will become different to is_valid_event() that I assume were intended to check whether the object has a valid value i.e. not empty or not random. However, is this check always implementable for all types?

There are the following reasonable approaches to improve this:

• Let NULL macro represent empty state and the validity functions can detect any invalid value passed e.g. empty or random. This might not be possible to detect for all types...
• Let NULL macros represent an empty state that can be detected by validity functions. This is reasonable in terms of implementation and should cover everything application code needs i.e. other random invalid states can be avoided by initialization to empty value.
• Let NULL macros represent an empty state that can be detected by relational operators (comparisons). Similar to above.
• Let NULL macros represent an empty state that can be detected by either helper functions or relational operators (comparisons). Hybrid solution that is likely more optimal considering that spec has never been clear whether operations are allowed or not.

While the main aim should be consistency for all types it might not be feasible to update the existing spec version or even the new version. So some hybrid scheme might continue to exist but be marked as depricated.

Another possible improvement we can make related to this area is to clarify whether any operations are allowed on these special types. The common understanding seems to be that they inherit behavior from opaque types however I don't think spec is explicit about this fact. In C opaque structs can't be used in operations but most commonly opaque types can only be used as pointers (otherwise objects can't be created from opaque types) which allows the operations... so I can see how there is a room for interpretations here as well...

Start with the OpenCL C 3.0 unified specification's “enqueuing kernels” section and the linked Clang IR and SPIR-V examples. Compare the NULL macro wording with the intended validity and permitted operations for special types; done means the specification has an agreed, consistent clarification across the affected types.