OpSource's third (File) parameter.

I’m just putting together a quick SPIR(-V) decoder/wrapper, but I haven’t used this instruction before and I’m not fully understanding this member (and I’m not yet sure how to get example code that uses these parameters).

https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpSource
Parameters 3 & 4 are optional.

What type is the 3rd parameter? (definitions from the page above)

  1. [embedded OpString instruction]? Doc says “File is an OpString instruction and is the source-level file name.”
  2. [word]? Doc says “Optional <id> File”. (where <id> usually means a word).

Also, is it possible that the 3rd parameter is omitted but the 4th is used? If so, how do I disambiguate whether the optional 3rd parameter is omitted.

If it’s #1, I guess I any valid OpString first word is an invalid null-terminated-string word, although this would be a pretty ugly way to disambiguate.
If it’s #2, how should I disambiguate between [an id] vs [the 1st word of a null-terminated-string (which might be 1 word)]?

Either way, does anyone else find the spec slightly ambiguous here?

Ok, pretty sure it’s a word (#2) - yay. - (as OpLine describes its OpString parameter similarly, but OpLine has a fixed size and said parameter must be 1 word).

Also, if you can’t have parameter 4 (text) without parameter 3 (file id) then there’s no ambiguity. But the spec doesn’t say this, so it’s still IMHO ambiguous.

The File operand is a one-word ID that references the result ID of an OpString instuction that should have appeared earlier in the instruction stream.

You can only have a 4th parameter (“Source”) if the 3rd paramter (“File”) is present.

There is type information in the boxes in the bottom of the instruction as well, not just the text in the main box. All physical instruction operands and <id> are defined in the spec to be 32-bit words, for all instructions, which should address the ambiguities.