[PATCH 4/7] Fix int overflow

[Mikhail Maltsev]

On 08.07.2015 1:48, Jeff Law wrote:
> I'm not questioning whether or not the test will cause a problem, but
> instead questioning if the test does what you expect it to do on a 32bit
> host.
> 
> On a host where sizeof (int) == sizeof (long), that len > INT_MAX test
> is always going to be false.
Yes, but in this case the call "d_identifier (di, len)" is also safe,
because implicit conversion from long (the type of len variable) to int
(the type of d_identifier's second argument) will never cause overflow.
I first wanted to change one of those types to match the other, but it
turned out that they are used rather consistently: all the code that
works with demangle_component.u.s_number.number uses type long (because
strtol was used for string-to-integer conversion before r73788), and
ints are used for lengths of various identifiers. Should I try to
refactor it somehow?

> If you want to do overflow testing, you have to compute len in a wider
> type.  You might consider using "long long" or "int64_t" depending on
> the outcome of a configure test.  Falling back to a simple "long" if the
> host compiler doesn't have "long long" or "int64_t".
So, it's probably vice-versa: the test is only needed if long is wider
than int.

> And a generic question on the testsuite -- presumably it turns on type demangling?
> I wanted to verify the flow through d_expression_1 was what I expected
> it to be and it took a while to realize that c++filt doesn't demangle types by
> default, thus Av32_f would demangle to Av32_f without ever getting into d_expression_1. 
Yes, the testsuite is based on libiberty/testsuite/test-demangle.c (OMG,
there are still K&R-style definitions there), and it uses (DMGL_PARAMS |
DMGL_ANSI | DMGL_TYPES) by default.

(snip)
> FWIW, demangler.com doesn't give any results for that case.  It just returns DpDv1_c 
But "_Z1fDpDv1_c" makes it crash :)

-- 
Regards,
    Mikhail Maltsev