develooper Front page | perl.perl5.porters | Postings from March 2008

Re: left_shift problem

Thread Previous | Thread Next
From:
Reini Urban
Date:
March 23, 2008 17:15
Subject:
Re: left_shift problem
Message ID:
47E6F2B5.7070505@x-ray.at
Yitzchak Scott-Thoennes schrieb:
> On Sun, March 23, 2008 3:45 pm, Reini Urban wrote:
>> What makes we wonder is why the IV/UV discrimination is stored in the op
>> (PL_op->op_private & HINT_INTEGER), and not taken from the type of the
>> 1st arg at TOPi - 1st pop, 2nd arg -, which is here also used as return
>> value.
>>
>> To my lisp trained eye, the signedness should be taken dynamically from
>> the variable, and not stored at compile-time in the function.
>>
>> At compile-time the compiler must check the type of the arg and store it
>> in the left_shift op. But what is when the type of the arg is upgraded from
>> an IV to an UV? Or vice versa. Is this possible, or is the IV guaranteed
>> to be static? Or, what if the arg is a UV, but the op has HINT_INTEGER?
>> Well, it is degraded to a signed than.

> I'm not sure I understand all those questions.  But maybe this will
> answer them:
> 
> By design, the numeric bit ops give their arguments UV context (or,
> under use integer, IV context).  If another type of numeric arg is
> provided, it is converted via a C cast (which doesn't quite match
> your terms "upgraded" or "degraded") and produce a UV-range (or, under
> use integer, IV-range) result.  Like all context application, it is
> something imposed on the operands by the operator.

Thanks! This explains it perfectly.

But still, the degration detail.
Assume UV 2^32-1 and HINT_INTEGER in the op =>
IV not representable.
left_shift would make it representable again, but the cast in
const IV i = TOPi; threw it away before, before shifting.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About