Bugzilla

(In reply to Nihanth Subramanya [:nhnt11] from comment #1)
> From a bit of research, I _think_ the issue might be that the C++ standard only specifies that an enum's underlying type, if not explicitly specified, should be any integer type wide enough to hold the largest value. I guess that could mean that the underlying type could end up being a signed 32 bit int since it's technically wide enough, even though the literal is suffixed. If this is right, it's likely that emitting an explicit type for the enum will fix the issue.

Ah, but maybe it's not trivial to do this if e.g. the IDL defines a combination of signed and unsigned values. Maybe an enum for each underlying type? i.e. if the IDL defines long, unsigned long, and unsigned int constants, we'd end up with three separate enums. 🤷‍♂️

(In reply to Nihanth Subramanya [:nhnt11] from comment #1)
> From a bit of research, I _think_ the issue might be that the C++ standard only specifies that an enum's underlying type, if not explicitly specified, should be any integer type wide enough to hold the largest value. I guess that could mean that the underlying type could end up being a signed 32 bit int since it's technically wide enough, even though the literal is suffixed. If this is right, it's likely that emitting an explicit type for the enum will fix the issue.

Ah, but maybe it's not trivial to do this if e.g. the IDL defines a combination of signed and unsigned values. Maybe an enum for each underlying type? i.e. if the IDL defines long, unsigned long, and unsigned int constants, we'd end up with three separate enums. 🤷‍♂️

edit: Thought about this a bit more and I do think that if we make it appear that one can control the type of a constant in the IDL syntax, then the generated code should preserve those semantics, so it's worth doing the enum-per-type approach. Otherwise we should not allow explicit typing on consts in XPIDL, since that information gets lost anyway. Still thinking about this.