Fix uniqint SIGSEGV for objects with no int overload

[zhmylove]

In case uniqint takes several objects, it always tries to call their int overload using amagic_call. This patch fixes the case when amagic_call returned NULL resulting into Segmentation Violation. Several tests are also added to ensure proper objects handling.

Problem:
The code below expected to work but crashes with SIGSEGV.

use List::Util qw( uniqint );
{ package Foo; use overload "+" => sub {1} }
uniqint bless {}, "Foo"; # Foo has no 'int' overload unlike Math::BigInt

| SvAMAGIC | AMG_CALLun | Current result | Proposed result |
+----------+------------+----------------+-----------------+
| false    | false      | else branch    | else branch     |
| false    | true       | else branch    | else branch     |
| true     | false      | SIGSEGV        | croak like int()|
| true     | true       | else bypassed  | else bypassed   |

[leonerd]

Hmm. This adds a new exception condition where there didn't used to be one. I wonder if that change in behaviour would break too much.

I'd prefer to preserve the existing condition, but without trashing the arg value. Instead, perhaps have:

SV *mgret;
if(SvAMAGIC(arg) && (mgret = AMG_CALLun(arg, int)))
    arg = mgret;
else ...

that way, it keeps the existing condition, but does not trash the value in arg when there is some magic but no int_amg.

[zhmylove]

Thanks!
Yes, I actually suggested this particular change in #137

But after that I thought a little bit more about that and decided to write this with croak just like int() does in this situation. Mostly due to uniqint() means literally: "remove subsequent duplicates based on int() values of the list supplied to it" and in turn int() does croak() for such objects.

This change will definitely not break any existing code as it croaks only instead of Segmentation Violation error which causes exit even inside eval

[haarg]

A croak seems appropriate to me, since that is what a missing overload does anywhere else.

[leonerd]

Ahyes. In that case, does the message match what would happen normally?

[haarg]

The message does not match.

But looking at the code for amagic_call, it isn't obvious why the previous code isn't already working correctly. It seems like it should already be producing an appropriate croak if the overload doesn't exist.

[leonerd]

The Perl 5.6 smoker looks unhappy, but looks like a machine setup issue, unrelated to this change.