Implementing UINT64_C in GLSL

[da3k]

I'd like to reuse a C header file in GLSL that makes use of the UINT64_C() macro. To make this work in GLSL, I'm enabling the GL_ARB_gpu_shader_int64 extension and defining UINT64_C() as follows:

#define UINT64_C(x) x##ul

Unfortunately, when the macro argument is a 64-bit value, the compiler generates the "hexadecimal literal too big" error before the macro is expanded. E.g.:

#define BLAH UINT64_C(0x12345678912);

Is this a bug or is this the intended behaviour?

Thanks,
Dae

[johnkslang]

It might be a specification question. ARB_gpu_shader_int64 says:

When the suffix u or U is present, the literal has type uint. When the suffix l or L is present, the literal has type int64_t. When the suffix ul or UL is present, the literal has type uint64_t. Otherwise, the type is int.

The core spec. uses inline notation to say:

integer-constant :
    hexadecimal-constant integer-suffixopt

integer-suffix : one of
    u U

But, the normative grammar at the end just expects a complete numeric token, not multiple tokens forming a single number, implying the above is how to form a token, and the core spec is only describing post-preprocessing tokens, not preprocessing tokens.

That is, GLSL grammar must receive an already fully formed numeric token, there is no suffix parsing.

I think that means it's bug (somewhere) to be error checking value overflow (from 32 to 64) while preprocessing.

However, even if fixing that, token pasting ## might be the next problem, as the functionality to piece together parts of numbers and then re-tokenize the result to get a different number might be missing. The retokenizing step is only present for some classes of tokens.

I think the missing pieces could be added for this case, as the number's bit pattern is already correct.

But, in the end, I think the problem will be the specifications themselves, as this requires either

1. the GLSL grammar to separately accept the numerics from the suffix, as two separate tokens, or
2. removing the rule that no suffix means type int and being more subtle, saying literals that overflow 32-bits are by default 64 bits, even without the suffix.

[stevec611]

removing the rule that no suffix means type int and being more subtle, saying literals that overflow 32-bits are by default 64 bits, even without the suffix.

This would be more consistent with what C/C++ specify?

[johnkslang]

Yes.