[cxx-abi-dev] Adding consistency check for C++11 forward-declared enums?

[John McCall]

On May 14, 2013, at 7:38 PM, Kevin Fleming <kevin at kpfleming.us> wrote:
> A discussion cropped up at C++Now today about the new forward declarations of enumerations in C++11. Much like forward declarations of functions, a forward declared enumeration consists of more than just a name; it also has an underlying storage type. This provides an opportunity for the enumeration's underlying type to be mismatch between a pair of TUs. If a translation unit forward-declares the enumeration with a different underlying type than the translation unit that defines the enumeration, any functions in in the interface between those TUs will disagree on the amount of data to be passed.
> 
> Even though there is no linker action require to 'resolve' forward-declared enumerations, it seems like the existing name mangling mechanisms and linker symbol resolution could be employed to provide a way for this situation to be identified. If the enum-defining TU exported a symbol with a suitably-mangled name of the enumeration, and the enum-consuming TU attempted to import such a suitably-mangled name (even though none of the object code in the consuming TU would ever reference the resolved symbol address), the linker would be able to notify the developer of the underlying type mismatch.
> 
> I see a long-tabled 'consistency checks' issue on the CXX-ABI pages that seems to address similar issues, but I figured I'd at least broach the subject to see if this is worth consideration.

Since the linker would need custom logic for this anyway, it would make more sense to just add a special section to object files with a bunch of key-value pairs in it instead of shoe-horning this into the symbol-resolution machinery.

It would be logical to use mangled names in the keys, of course.

That said, since the underlying type has to appear and match on every declaration of the enum (including the eventual definition), ABI mismatches on this feature seem comparatively unlikely.

John.