c++ 20 raises a warning for "bitwise operation between different enumeration types ... deprecated"

[MarkCallow]

The macros in khr_df.h were fixed some time ago to prevent this warning by the addition of uint32_t casts.

The dfd tests in KTX-Software's unittests (which should be moved to dfdutils after the cmake build and CI is set up), have several instances of code like

KHR_DF_CHANNEL_RGBSDA_ALPHA | KHR_DF_SAMPLE_DATATYPE_LINEAR

which triggers the warning. The code uses this pattern when setting the channel type parameter to a constructor used for building test DFDs. I do not know how common this pattern is in the wider world. If it is thought to be a common pattern then it will be helpful to add the following macro to khr_df.h

#define KHR_DF_CHANNEL_TYPE(id, q) \
    ((uint32_t)KHR_DF_CHANNEL_##id | (uint32_t)KHR_DF_SAMPLE_DATATYPE_##q)

This avoids having to remember to add casts everywhere.

@fluppeteer is this a worthwhile addition?

[fluppeteer]

Probably no harm in adding it if it's useful. I'll say thought that I've been badly burnt by this kind of C preprocessor macro in the past (notably when trying to grep an entire source tree for where some constants were defined, and their definition was going through a macro, so the point of definition didn't contain the full constant name); Stroustrup has been known to say the C preprocessor is evil and should die (and that was decades ago). Still, that's the problem of anyone choosing to use this; I might be hesitant of actually using this to define anything in the header.

If it's not urgent (as in it could wait a few weeks) I'll try to get it in the next update? I do hope to have another update soon.

[MarkCallow]

It is not urgent. I have created the same macro, minus the KHR_ prefix, in the unittests code.

I do not, and am not planning to, use this to define anything else. I use it purely to build a channel type value to pass as a parameter to a constructor.

[fluppeteer]

Thanks, Mark. Feels like there ought to be a nicer way to do it in C++ anyway, so maybe the answer is to do some separate representation for the C++ side. I'll have a think.