[cxx-abi-dev] A complexity in the mangling ABI

Mark Mitchell mark at codesourcery.com
Mon Nov 24 02:09:26 UTC 2003


> This is all a long-winded way of asking why the ABI says that
> order-insensitive vendor extended type qualifiers may not be subset
> for purposes of substitution.  If this restriction were lifted--if
> only the standard CV-qualified type could not be subset--then I
> believe that it would be possible to write a correct demangler which
> was not aware of all vendor extended type qualifiers.

The paragraph you quoted talks about "the grammar" but as with many aspects
of the ABI specification, the wording is not ideal.  I think that paragraph
means to be talking about the ordering requirements on something like "const
volatile int"; the ABI specifies the order in which the "C" and "V" appear,
and requires that vendor-extended qualifiers appear in alphabetical order.

The specification doesn't actually say how to deal with mangling
order-sensitive qualifiers.

If there are vendor-extended order-sensitive qualifiers, that would clearly
need to change.

As for adding additional substitution candidates (like "const foo" given
"const volatile foo", or "vendor1 foo" given "const vendor1 vendor2 foo")
might very well increase the number of substitution candidates substantially
without major benefit.  Once you exceed 36 substitution candidates the
number of digits in the substitution reference increases, so that would
increase the cost.  Furthermore, the obvious way to organize the
substitution table in the compiler is to have a dictionary mapping types to
substitution numbers; if "const volatile foo" resulted in adding "const foo"
to the table you might have to create a type which would otherwise be
unncessary.

I'm not sure what the historical justifications were for the restriction you
quoted.

-- Mark




More information about the cxx-abi-dev mailing list