On 07/09/2015 10:48 PM, Mikhail Maltsev wrote:
On 08.07.2015 13:55, Ian Lance Taylor wrote:
I don't know of anybody who actually uses the DMGL_TYPES support. I
don't know why anybody would.
Ian
Thanks for pointing that out. I updated the testcases, so that now they
don't depend on DMGL_TYPES being used.
But better still is to consider the larger context. We want the
demangler to work the same on all hosts, if at all possible.
d_identifier is called exactly once. Change it to take a parameter of
type long. Don't worry about changing d_source_name.
Fixed.
Then look at the fact that d_number does not check for overflow. We
should consider changing d_number to limit itself to 32-bit integers,
and to return an error indication on overflow. From a quick glance I
don't see any need for the demangler to support numbers larger than 32
bits. I think it's OK if we fail to demangle symbol names that are
more than 2 billion characters long.
OK, but I think it'll be better to fix that in a separate patch.
The attached patch includes the changes mentioned above, there is also a
small change: I moved the comment for CHECK_DEMANGLER macro to
cp-demangle.c (it already contains a comment for other similar macros)
and replaced __builtin_abort() with abort(). For some reason I thought
that it might need an additional #include, but in reality libiberty (and
the demangler too) already use abort().
The changelog is also attached. OK for trunk after regtest?
OK after regression testing.
jeff
