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

Re: left_shift problem

Thread Previous | Thread Next
From:
Yitzchak Scott-Thoennes
Date:
March 23, 2008 16:06
Subject:
Re: left_shift problem
Message ID:
45829.71.32.84.230.1206313561.squirrel@webmail.efn.org
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.



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